Hello Will,

> Thanks for the comprehensive list!
> Your suggestions are good in that they don't involve *too* much change
> from what we're used to. 

That was largely because I'm broadly happy with the situation "as is".
I was thinking about the small-ish number of awkward cases, and trying
to make them clearer.

> 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.

I did my best to stick with the current thinking (letters are based on
an explanation of what they do).  You could perhaps include "z" in my
list as a complement to "W", with z representing other expansion
possibilities and W being more strictly for delimited arguments.  In
that way, a z argument with always represent one thing, whereas W can
mean any arbitrary list of stuff.

>      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> }

Speaking from my own experience, I quite like the :T, :F, :TF idea.  The
problem with the above is that \tlist_if_in_TF:nn needs four arguments,
so it should really be \tlist_if_in_TF:nnnn.  I think it is then much
harder to see what is going on.  So if it were down to me I'd keep the
T/F idea, although I'd aim for lower case as these can take braced
arguments. (Speaking of which, I might revise my suggestion again, to
stick with :w in lower case for the same reason: braces are possible for
:w arguments.)

> (Although I suppose there's no reason we couldn't currently write
>   \bool_double_if:NN_TT_TF_FT_FF )

Why not just \bool_if:NN_TT_TF_FT_FF?  A slight abuse of the system, but
this is one of those edge cases where flexibility is needed.

> While we might be able to create a better system than we've got now, is
> it worth it?

Once again, if it were down to me I'd not make more changes than are
really needed.  In that sense, this entire discussion could be somewhat
redundant: things already work reasonably well.  I'd still argue that
\exp_after:NN is not representative of what it does, so using the
current specifiers would prefer \exp_args:NE.  That change at least
should be relatively easy.

If other changes are made, I'd suggest that there will be something of a
"knock on" effect, and so it is only worth doing if the entire result is
more logical (e.g. just changing f => s is not worth it).  Of course, I
think my suggestion is not bad :-)
-- 
Joseph Wright