AllowUsers "logic" and failure to indicate bad configuration

[mpatton at inforelay.com]

I smacked into this previously reported bug today whereby an invalid
keyword in the Match{} stanza did not throw an error on configuration
reload. Are there any plans to fix this? Likewise the penchant for some
fields to be comma separated and others to be spaces is just asking for
mistakes. Why not support both and be done with it? There was no response
(that I saw in the archives) to this post
http://marc.info/?l=openssh-unix-dev&m=132311628508429&w=2

Like him, I'm using 5.3p1 as packaged in CentOS 6.3.

Secondly the Allow/Deny logic is downright tortured. I looked back and
again didn't come across any good discussion as to why it was written that
way. It should not be necessary for AllowUsers to be the superset of
AllowGroups. As Spock would say "it is illogical." If you had to write PF
rules like that you'd go crazy. That's why most people use first-match
logic.

Per the manpage, if the logic is DenyUsers > AllowUsers > DenyGroups >
AllowGroups, then there has to be a immediate stop to the logic chain at
each stage.

if $user ~= %DenyUsers; then ( deny; return )
if $user ~= %AllowUsers; then { allow; return )
if $user member of %DenyGroups; then (deny; return )
if $user member of %AllowGroups; then (allow; return )
if (%AllowUsers != null || %AllowGroups != null); then deny

Anything else makes no sense. Can we expect a change in the future? Or if
I were to submit a patch to fix this, would it be accepted?

The other flaw I see here is the treatment of 'root'. There are already
special keywords controlling that UID, so it makes no sense to have to tag
'root' into this logic either. PermitRootLogin is supposed to be
sufficient to dictate that particular outcome.