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