Thus spake David Laight ("DL> ") sometime Today...

DL> > I.e. the new feature should work like "sh -c", and thus "su -c" et al,
DL> > and that anyone wanting to use the new feature must use the new syntax.
DL>
DL> Erm sh -c doesn't (and shouldn't) work that way.
DL> 	sh -c -x command -y
DL> is the same as:
DL> 	sh -x -c command -y

A bit far afield but since the common direction seems to be touting
POS-ix, one would think that sh knew how to parse options in a similar
manner to, or in fact use, getopt(3), and abide by its constructs; i.e.

sh -c -x command -y would (try to) execute "-x", while
sh -x -c command -y would (try to) execute "command".

[note that quotes are needed around "command args..." in order to get
it to work properly.]

Regarding su:  Since 'su' with no args denotes 'su root', should not
"su -c 'command args...'" execute "command args"?  Perhaps that's
not the way it's ever worked, but it would seem to make the most sense.
Otherwise we should *gag choke* _require_ a username and not assume
a default -- or does that break other things (like user habits and
POS-ix compliance)?

I just R'd TFM and I note that we have added [ -c login-class ] to the
syntax.  Should that have been better thought out and done as -C?

By comparison with Solaris, our sh is broken, btw:  Solaris behaves
as expected.

Solaris' su, as well as ours, mandates a username unless used in its bare
form.  This still does not make sense to me if it is designed for
consistency, which, evidently, it appears not to have been.

...am I making any sense, here?

				--*greywolf;
--
NetBSD: Servers' choice!