It might not be necessary to set OneSync as the default launcher of files to get coauthoring working

[catmanjan]

IStorageProviderHandler lets you emit a URL, at least for cloudsyncroots - perhaps it even works for non placeholder files? I've never tried

[madeyouclickstudio]

Good catch — this would let us drop the default-app workaround entirely if it works.

For context: real cloud sync providers (OneDrive, Google Drive) register via StorageProviderSyncRootManager.Register() and implement IStorageProviderHandler so Office can ask for the cloud URL of a given file and reroute the open through ms-word:ofe|u|<url> itself. That's why OneDrive doesn't need to be set as the .docx default — Office detects the sync root, queries the provider for the URL, and reopens against the cloud.

OneSync's architecture today uses Dokan (generic user-mode filesystem), so the drives aren't registered as sync roots and the files aren't CFAPI placeholders. Office has no reason to suspect the files are cloud-backed, which is why we currently sit in front of the file association and rewrite the open ourselves.

Two unknowns before this is a clear win:

1. Whether Office actually queries IStorageProviderHandler for files that aren't CFAPI placeholders. The handler is in theory independent of the placeholder state, but Office's cloud detection has historically required CFAPI placeholders. Untested against Dokan-backed sync roots.
2. Whether registering a Dokan-mounted folder as a Storage Provider Sync Root collides with the existing Dokan mount — overlay handlers, shell extensions, drive-letter root semantics all in play.

Minimal experiment to settle it:

• Register one OneSync drive as a sync root via StorageProviderSyncRootManager.Register()
• Implement an IStorageProviderHandler that returns the SharePoint webUrl for a queried file (we already have that mapping in MetadataStore for the existing --launch-office path)
• Open a .docx from that drive with Office NOT set as the .docx default and watch whether Office invokes the handler

If it works, we can rip out OfficeRedirect.Docx / the ProgID + DocxAssociation MSI machinery and the per-user UserChoice retraining notes in the FAQ. If not, the current approach stays.

PR with a proof-of-concept very welcome — happy to merge once we can confirm Office picks it up.