I tested this against Xcode 27 beta 3 and the macOS 27 SDK. The new handler-style FSKit API gets close, but FSContext currently exposes only the caller’s real/ effective UID and GID. For a process-scoped Nix store, two processes owned by the same user may need to see different store paths. Visibility is determined by a selected process and its descendants, so the filesystem needs a stable PID, audit token, or equivalent per- process identity. UID/GID alone isn’t sufficient. Because /nix/store objects are immutable, file-data cache coherency isn’t a concern. The remaining caching question is namespace visibility: can positive or negative lookup results and vnodes be reused across callers without invoking the context-aware FSKit handler? For example, one process may resolve /nix/store/X, while another same-UID process should receive ENOENT. A cached positive or negative lookup must not leak between those views. Could Apple clarify: Is there a public way to obtain the initiating process identity or audit token from FSContext? When lookup results depend on FSContext, does FSKit guarantee that the handler is invoked for each caller despite name/vnode caching? If the second guarantee already exists, process identity may be the only missing capability. Otherwise, this use case would also need caller-scoped namespace caching or a way to disable positive and negative lookup caching.