I'm opinionated in not breaking it for id-kp-serverAuth (at least not until we're off libpkix), since it was important to address https://nameconstraints.bettertls.com/
While the fix was "obviously" wrong, libpkix is already supposed to have the 'right' logic, by way of
includeSubjectCommonName as part of the constraint check, which libpkix passes through from
PKIX_PL_Cert_CheckNameConstraints, and which it computes based on whether the terminal cert being verified contains
This is the correct behaviour; when considering whether a name constraint is violated, one doesn't do this by trying to determine the set-intersection of the given chain. Instead, if any subordinate certificate violates the parent certificate constraint, it's an invalid chain, and doesn't even get to name validation.
libpkix is ensuring that, if the cert is capable of being used as a server cert, it's actually compatible with that constraint. In this case, the absence of the SANs, and the presence of id-kp-serverAuth, it does the check.
The specific logic is https://dxr.mozilla.org/mozilla-central/rev/8ac0a35be0d35f9f5aba38ed841cb3d03a2ae3c8/security/nss/lib/libpkix/pkix/checker/pkix_nameconstraintschecker.c#191
If you wanted to change that, so it only enforces that check if verifying as a server cert (which I think is both less consistent with how other nameConstraints are processed and more of a security risk), changing how pkix_NameConstraintsChecker_Check is invoked, so that it can know the client's desired use case, would be how to do it. I think that would be a security issue, though :)