Thanks — I followed your suggestion and replaced the rm/mv tests with a small C probe that invokes rename() and unlink() directly and records the return value, errno, and lstat() state before and after each syscall. Environment: macOS 26.5.2 (25F84), path-backed FSUnaryFileSystem, with same-directory operations at the volume root. I also ran the identical binary against the native temporary filesystem as a control. Results: Plain rename(source, destination) with no existing destination succeeds both natively and through FSKit. FSKit dispatches renameItem, and the extension’s backing rename() succeeds. Replace rename(source, destination) with an existing destination succeeds natively but returns -1/ENOENT through FSKit. Immediately before the failing syscall, both source and destination successfully lstat() as regular files. Both are mode 0644, uid 501, gid 20, and flags 0. They are children of the same writable root directory, which is mode 0700, uid 501, gid 20, and flags 0. Immediately after the failure, both files still exist unchanged. The result is identical when the files are created through the mounted volume and when they are pre-seeded directly in the backing directory before mounting. This appears to rule out an issue specific to the attributes returned by createItem. During one replace-rename attempt, the extension receives 1,026 successful lookups for the source and 1,026 successful lookups for the destination, with corresponding successful attribute requests, but receives no renameItem call. A direct unlink() returns success, but removeItem is not dispatched. An immediate lstat() still sees the item; our historical FSEvents workaround removes the backing item shortly afterward. The same extension handles plain rename correctly, and the same metadata is presented for the replace case. Is there an attribute or capability that VFS uses specifically for overwrite rename which would cause it to return ENOENT after repeatedly and successfully looking up both items? Are the 1,026 lookup retries expected behavior? Is there another VFS/FSKit diagnostic channel you would recommend capturing to identify why dispatch stops before renameItem?