Hey Joseph, Thanks for the comprehensive list! Your suggestions are good in that they don't involve *too* much change from what we're used to. You got me thinking along the lines of some ideas Frank wrote down about a year ago. As you will see, this set of arg specs change things around quite a lot! In the following table, "W" is a tentative suggestion following from some comments by Frank last year; "J" is Joseph's suggestion, and "C" is what we've got now. W J C Input Output Description S N N Single token Unbraced No expansion U E Single token Unbraced One expansion T O O Single token Braced One expansion U D Single token Braced Double expansion V Single token Braced Triple expansion W Single token Braced "Special" expansion Z X X Single token Braced Full expansion Which of these do we really need? - 'O' is needed for \glet:Oc -- or is it? Would writing \glet:oc be *that* bad? - 'N' is obviously needed - Can 'E' and 'X' be accommodated by 'e' and 'x' ? n n n Braced tokens Braced No expansion a o o Braced tokens Braced One expansion b d d Braced tokens Braced Double expansion c d Braced tokens Braced Triple expansion f s f Braced tokens Braced "Special" expansion x x x Braced tokens Braced Full expansion s Braced tokens Unbraced No expansion t u e Braced tokens Unbraced One expansion u Braced tokens Unbraced Double expansion v Braced tokens Unbraced Triple expansion w Braced tokens Unbraced "Special" expansion z Braced tokens Unbraced Full expansion These aren't that intuitive but on the other hand wouldn't be used too often. Alternatively, they could be n!, a!, b!, ... with Morten's suggestion. N c c Braced tokens (Un?)braced Tokens to csname A e C Braced tokens Braced To csname, expand once B Braced tokens Braced To csname, expand twice C Braced tokens Braced To csname, expand thrice F Braced tokens Braced To csname, expand full X Braced tokens Braced To csname, expand all K R/K D Varies Varies Reserved/kernel only W W w Varies Varies "Weird" argument p P p Parameters n/a Primitive TeX parameters t T Braced tokens Braced True branch f F Braced tokens Braced False branch What would happen if we dropped the true/false flags from the arg spec into the function names? E.g., \tlist_if_in_TF:nn { <tlist> }{ <str> } { <true> }{ <false> } It's not perfect, but I think it's okay. It does remove the "funny case" that 'T' and 'F' branches represent in the argument specifications. And it would allow an arguably better syntax for bool_double: \bool_double_if_TT_TF_FT_FF:NN (Although I suppose there's no reason we couldn't currently write \bool_double_if:NN_TT_TF_FT_FF ) *** Now, it would be a BIG JOB to actually make these changes. (Hmmm, maybe not. I guess regular expressions could do it without too much hassle.) While we might be able to create a better system than we've got now, is it worth it? W