J.Fine wrote:
>> Sorry, I'm a bit lost!  Which bit of the thread are we talking about?
>> (xparse as-a-concept, post-processing arguments, how to specify
>> arguments, ... )
> 
> All of the above, taken together.
> 
> One starts with parsing key-value arguments in TeX macros, then further features are required, and you start adding features to the LaTeX macros for list processing and the like, and before you know it something has arise that is too complicated for TeX macros.

As I see it, the basic idea of xparse is to separate how user functions
expect input (stars, optional arguments, mandatory arguments, etc.) from
how internal functions work (fixed numbers of mandatory arguments). To
do this, the idea is to create \newcommand-on-steroids, so that complex
arguments can be processed. For example, \newcommand can't even make two
optional arguments or look for a star.

So if we take the common example of \section, the code at present mixes
input syntax and internal workings. The plan would be to replace it with
something like:

\DeclareDocumentCommand \section { s o m } {
  % Code here
}

where the code always has three arguments #1, #2, #3 to pass down to the
underlying structure. The idea is it is then possible to alter input
syntax without touching most of the code.

There are several questions then to be answered. Some answers agree with
your analysis. For example, on verbatim input I feel it has to be done
"by hand", and it looks to me like we are generally moving that way. On
the other hand, I think the basic idea (as illustrated above) works
okay: the code does exactly what is expected (using the original
implementation or my xparse-alt experiments). On the post-processing
question, I probably tend to the "do by hand" side again: I'm not sure
that the need justifies the extra complexity (of code or of input).
However, if the consensus is that it is needed, then I'm keen to do the
best job possible on it.

Hope this makes clear what is going on (at least as I understand it!).
-- 
Joseph Wright