Will Robertson wrote: > In order of preference, I think I like idea 1, then 2, then 3. It seems > like with the current system, we can't really anticipate every > possibility of weird expansion that comes along. I think that you have to accept that not everything will fit into a neat set of characterisations. The key is to cover enough cases to make sense. For example, whatever you do about \exp_after:NN, it will always be a bit odd (but I'd suggest not using :w, which I think is not the case most of the time!). > > Arg specs n, N, w, D, e, E can be ignored for this discussion, so here's > what's left: (since an 'n' argument has no added braces) > o O > x X > C > f > d I'd suggest the following: New Current Input Output Description D D Varies Varies Do not use (kernel only) E E Single token Unbraced One expansion N N Single token Unbraced No expansion O O Single token Braced One expansion P p Parameters n/a Primitive TeX parameters W w Varies Varies "Weird" argument X X Single token Braced Full expansion c c Braced tokens Braced Tokens to csname e e Braced tokens Unbraced Expand once f F Braced tokens Braced False branch n n Braced tokens Braced No expansion o o Braced tokens Braced One expansion s f Braced tokens Braced "Stop" expansion t T Braced tokens Braced True branch u d Braced tokens Braced Double expansion v C Braced tokens Braced To csname, expand once x x Braced tokens Braced Full expansion My thinking here is that all of the capital letters take unbraced arguments, and all of the lower case ones take braced ones. I've tried to keep lower and upper case behaviour the same. I struggled a bit with the existing "C": I've not actually used that one at all. "v" is next to "c" on a QUERTY keyboard! -- Joseph Wright