Should currentSyncAnchor(completionHandler:) return a global version number of the backend, or one scoped to the enumerator's container identifier? What should we return if the backend has no per-container version? Also, how does the system use this anchor? It appears to be followed by enumerateItems(for:startingAt:), but nothing seems to guarantee the anchor hasn't changed in between. Is there an atomicity expectation here?

Enlarging the working set is straightforward — every item returned from enumerateItems(for:startingAt:) becomes part of it. But how do we safely remove items? If we exclude a folder from working-set change enumeration, the system shows the user an obsolete version of that folder, because it never calls enumerateItems(for:startingAt:) for it again. (Note: It seems system does call enumerateItems(for:startingAt:) again for materialized folders after extension restart.) What's the intended way to evict items from the working set?

On a folder's first visit, the system materializes it via enumerateItems(for:startingAt:). Subsequent visits don't re-enumerate; freshness seems to rely on enumerateChanges(for:from:) on the working set. However, after an extension restart, visiting an already-materialized folder triggers enumerateItems(for:startingAt:) again — even though working-set changes were already consumed. So is enumerateChanges(for:from:) not the sole channel for keeping materialized items fresh? Under what conditions does the system re-enumerate a materialized folder?

In an NSFileProviderReplicatedExtension, is enumerateChanges(for:from:) ever called for enumerators other than .workingSet, or is it exclusively used for the working set?