Thanks—I replaced rm/mv with a C probe calling rename()/unlink() directly on macOS 26.5.2, plus native controls. Plain rename succeeds and dispatches renameItem. Replace rename succeeds natively but returns ENOENT via FSKit: both 0644 files exist before/after, whether created via mount or preseeded; 1,026 successful lookups each, no renameItem. unlink() succeeds, no removeItem; our FSEvents workaround removes it later. Which overwrite-specific VFS check could block dispatch?

Good point for the original example. In my reproduction, however, I used log stream --level debug plus a separate diagnostic log. Plain rename records renameItem; overwrite rename produces 1,026 successful lookups for both files but no renameItem, while rename() returns ENOENT. For unlink, no removeItem is captured and the file disappears only through our FSEvents workaround. So hidden info messages don’t explain my results.

Good point for the original example. In my reproduction, however, I used log stream --level debug plus a separate diagnostic log. Plain rename records renameItem; overwrite rename produces 1,026 successful lookups for both files but no renameItem, while rename() returns ENOENT. For unlink, no removeItem is captured and the file disappears only through our FSEvents workaround. So hidden info messages don’t explain my results.