Supported descriptor-bound distinction between absent and empty ACLs on macOS Monterey

Reported environment: macOS Monterey 12.7.6 (build 21H1320), Intel, APFS. The filesystem type of the relevant volume and exact installed implementation have not been independently reverified.

I need a supported, read-only way to distinguish an absent filesystem ACL, an explicit zero-entry ACL, and unavailable/unsupported/invalid/incomplete ACL evidence while retaining an open descriptor to the object.

One retained observation: an existing empty regular file was opened read-only with O_NOFOLLOW and O_CLOEXEC. Path and descriptor metadata matched the expected identity, owner, mode and link count before and after the call. Exactly one acl_get_fd_np(fd, ACL_TYPE_EXTENDED) call returned NULL. Errno was cleared immediately before the call and immediately captured afterward as ENOENT. Descriptor closure succeeded. This observation does not establish ACL absence or identify the internal error path. File creation and private mode are not treated as proof of no ACL.

I have not tested fgetattrlist on this host, created ACL fixtures for this inquiry, or established volume ACL capability results.

Apple's published Libc-1507.100.9 source shows the fstatx_np/filesec property path, and xnu-8020.140.41 shows mode-dependent extended-security attribute packing. I am treating those as version-specific implementation evidence, not as confirmation of the installed implementation or a complete supported API contract.

For this reported configuration:

1. Which supported descriptor-bound API sequence and checked preconditions distinguish these three states? A contract applicable to Monterey and the relevant filesystem is sufficient; I am not asking for a guarantee across every macOS version or filesystem.
2. Does NULL/ENOENT from acl_get_fd_np have a supported ACL-absence meaning under specified conditions? Can an explicit zero-entry ACL produce the same result, and how should it be distinguished?
3. With fgetattrlist requesting ATTR_CMN_RETURNED_ATTRS and ATTR_CMN_EXTENDED_SECURITY, can an omitted security returned bit ever establish absence rather than unavailable evidence? Do legacy packing or a valid filesystem capability result supply a supported distinction? Please specify the applicable conditions.
4. Does successful fstatx_np followed by filesec_query_property for FILESEC_ACL reporting an unset property distinguish absence from an unavailable observation?
5. When a complete, valid security record is returned, what is the supported interpretation of KAUTH_FILESEC_NOACL versus an explicit entry count of zero? Is this representation intended for application-level absence verification?

Please identify applicable documentation or supported technical guidance, including failure/unknown handling. Genuine retrieval errors must remain errors, and ambiguous or incomplete evidence must remain unknown. I do not want to infer success from an error, omitted attribute, invalid default or empty display, or modify an object's permissions/ACL to establish its prior state.

References consulted:

• Apple's ACL getter manual
• Apple Libc-1507.100.9 ACL getter source
• Apple xnu-8020.140.41 attribute manual