> strong deviation from that. (this is independent of the fatc that
> there may be a completely different approach to document level
> syntax, eventually, but this is not what xparse was meant to be).

I'm guessing that "completely different approach[es] to document
level syntax" have been discussed earlier. Any pointer to such a
discussion on this list?

> -snip-
> to break between arguments (rather than inside)
> -snip-
> Now one could argue that that this  behavior for \\ is useful

Ok, I retract my previous proposal: it makes a lot of sense to want a
consistent user interface. Then always skipping spaces is probably
best. For \\, I am thinking that perhaps removing the optional
argument completely, and replacing it by a look-ahead for \vspace is

\\ [1cm]  => \\ \vspace {1cm}

of course allowing spaces. Then we wouldn't have this odd exception anymore.

> have to implement a full blown scanner yourself and  disable TeX's internal
> scanner completely

It should be enough to make spaces active, but then comes the task of
removing spaces at the beginning and end of lines, and converting
several spaces in a row, etc. A huge mess.

> here is my summary
> allow spaces but not \par between arguments
> do not allow spaces between arguments
> leave it to the command how spaces between arguments are interpreted

I agree with all the pros and cons mentionned by Frank. However, I
think you forget one possibility (which is the current xparse
approach): trailing optional arguments do not ignore spaces, except if
the command is a control word with no mandatory arguments. Ugly,
slightly difficult to remember, but consistent. Though I'm now
convinced that the LaTeX2e approach is probably the simplest.