This document details thirteen library-specific records concerning the implementation of X.509 Name Constraints. These records highlight inconsistencies in how various TLS libraries handle these constraints, leading to situations where a name accepted by one library might be rejected by another. Some of these issues have been resolved, while others are still under review or were not deemed security vulnerabilities. Name Constraints are designed to confine Certificate Authorities (CAs) within a defined namespace. Discrepancies exist in handling DNS name case sensitivity and wildcard matching, with libraries like GnuTLS and Go exhibiting varied behaviors. pyca/cryptography was found to validate constraints against SANs but not against the requested peer name. Libraries also differ in how they treat IPv4 and IPv6-mapped IPv6 forms for IP address constraints. URI handling presents further inconsistencies, particularly regarding host extraction from URI SANs. AWS-LC and s2n-tls have reported issues with wildcard Common Name fallback when leaf certificates lack SANs. Mbed TLS, in a specific configuration, does not enforce non-critical Name Constraints, contrary to RFC 5280 requirements. The impact of these inconsistencies is relevant only when an attacker can forge a trusted signature and exploit a validation path for authorization. CERT/CC is coordinating remediation efforts with affected projects, with varying statuses reported for each library. Operators relying on Name Constraints are advised to verify their libraries' behavior and prioritize explicit SANs and issuance policies.