Limited certificate path validation only? are extensions accounted for?

There are many valid/standard extensions that apply to the scope of 'Validate the certificate path'

It appears key usage and basic verification (i.e. OpenSSL only validates hostname, expiry, and root trust) are only considered for Valid certificate path in this library, It does not seem that it is respecting extensions that should also apply.

The simplest example I can think of is the InhibitAnyPolicy because you state it is not done:

# Steps 1 d-f
# We do not use initial-explicit-policy, initial-any-policy-inhibit or
# initial-policy-mapping-inhibit, so they are all set to the path length + 1

But it is just a fairly straight forward counter i.e. https://cryptography.io/en/latest/x509/reference/#cryptography.x509.InhibitAnyPolicy

The inhibit anyPolicy extension indicates that the special OID ANY_POLICY, is not considered an explicit match for other CertificatePolicies except when it appears in an intermediate self-issued CA certificate. The value indicates the number of additional non-self-issued certificates that may appear in the path before ANY_POLICY is no longer permitted. For example, a value of one indicates that ANY_POLICY may be processed in certificates issued by the subject of this certificate, but not in additional certificates in the path.

So there must be some reasoning to just set it to path +1 and not use it? There are a few more comments that have some inherent rationale that is not documented, this one stood out to me but I see others and all really should have the rationale explained in the documentation because the documentation leads us to believe all relevant (i.e. critical extension) checks are performed

The next one that comes to mind that is fairly straight forward to write about is;

subjectKeyIdentifier of the root CA cert should match the authorityKeyIdentifier of the next cert in the chain, and so-on. And I believe this is not taken care of in this library, which is an assumption because I've tried using self-signed.badssl.com which has neither of these and the chain was seemingly able to be validated (not throwing exceptions with missing subjectKeyIdentifier or authorityKeyIdentifier), albeit self-signed so not in any root CA store and ultimately reported invalid.

Does this library aim to properly and completely 'Validate the certificate path'? Or is it only accounting for basic OpenSSL verification + key usages? If it is not aiming or already actually applying complete 'Validate the certificate path' as it claims, you might want to consider updating the docs and main message you're project is stating.

Maybe 'limited certificate path validation, and aim to eventually be a complete certificate path validation solution for python'' would be more accurate?

Start by reading the cited sections of validate.py and path.py, then compare their certificate-path handling with the documented validation scope and the referenced InhibitAnyPolicy behavior. Determine which extensions are intended to be supported and whether the documentation accurately states that scope; done requires an agreed validation or documentation plan.