Yes, problem resolved - it turned out that I was returning a contents size in the FileProviderItemIdentifier that didn't match the size on disk, which resulted in this unexpected call to upload the same content as was downloaded.

Any ideas @clenart? (FYI I haven't heard any response to my bug report yet either)

I have filed a feedback report as requested: FB12673356 (FileProvider's modifyItem being called immediately after fetchContent receives updated content). Thanks for the help!

The only changeFields is .contents (contentModificationDate is not present unlike when the content is actually modified locally). No options values. My understanding is that the system expects the contentVersion to change during the enumeration update to act as a signal that new content is available and therefore fetch the content (given the item is in the working set). Are there similar expectations the system has that could be triggering this modifyItem call when it shouldn't be?