Hi Marco let's start with the bottom of your mail: > > I hope it's ok to post my thoughts here. > that's the purpose (even though not that much used) >> The team intend to modify the existing \<thing>_case:nnn functions, >> renaming the last argument as 'F'. This reflects the fact that this >> final argument is used only when the test case (<thing>-dependent) is >> logically false, and follows the approach used elsewhere. > I think it's not a good decision. The argument specifier F implies for > me that there is also a true part (T). So I would prefer to use > \<thing>_case:nnn. As Joseph said, there are other similar cases. And in my view if you request a selection (and you fail to match) then the else is a natural F In fact one could think of also having \<thing>_case:nnTF where the T branch is selected if you have a match (in addition to executing any match code from the "n" argument). I personally rather liked that I idea, as it fits well with other places like \prop_get:NnN(TF) cheers frank