In my investigations:
OneDrive can run in Big Sur without FileProvider, in OneDrive, each placeholder file have a xattr named com.apple.fileutil.PlaceholderData, and bound with a launch service xattr com.apple.LaunchServices.OpenWith.
Evidence:
$ xattr -l 'Getting started with OneDrive.pdf'
com.apple.LaunchServices.OpenWith:
00000000 62 70 6C 69 73 74 30 30 D2 01 02 03 04 57 76 65 |bplist00.....Wve|
00000010 72 73 69 6F 6E 5F 10 10 62 75 6E 64 6C 65 69 64 |rsion_..bundleid|
00000020 65 6E 74 69 66 69 65 72 10 00 5F 10 24 63 6F 6D |entifier.._.$com|
00000030 2E 6D 69 63 72 6F 73 6F 66 74 2E 4F 6E 65 44 72 |.microsoft.OneDr|
00000040 69 76 65 2E 44 6F 77 6E 6C 6F 61 64 41 6E 64 47 |ive.DownloadAndG|
00000050 6F 08 0D 15 28 2A 00 00 00 00 00 00 01 01 00 00 |o...(*..........|
00000060 00 00 00 00 00 05 00 00 00 00 00 00 00 00 00 00 |................|
00000070 00 00 00 00 00 51 |.....Q|
00000076
com.apple.fileutil.PlaceholderData:
00000000 44 45 4E 4F 01 00 00 00 03 00 00 00 50 01 00 00 |DENO........P...|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 02 00 00 00 30 01 00 00 00 00 00 00 00 00 00 00 |....0...........|
00000030 03 13 06 00 00 00 00 00 33 32 37 33 41 46 43 44 |........3273AFCD|
00000040 35 36 41 41 36 45 35 37 21 31 30 32 00 00 00 00 |56AA6E57!102....|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 33 32 37 33 41 46 43 44 35 36 41 41 36 45 35 37 |3273AFCD56AA6E57|
00000070 21 31 30 32 00 00 00 00 00 00 00 00 00 00 00 00 |!102............|
00000080 00 00 00 00 00 00 00 00 33 32 37 33 41 46 43 44 |........3273AFCD|
00000090 35 36 41 41 36 45 35 37 21 31 30 31 00 00 00 00 |56AA6E57!101....|
000000A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000120 00 00 00 00 00 00 00 00 33 32 37 33 61 66 63 64 |........3273afcd|
00000130 35 36 61 61 36 65 35 37 00 00 65 00 74 00 74 00 |56aa6e57..e.t.t.|
00000140 69 00 6E 00 67 00 20 00 73 00 74 00 61 00 72 00 |i.n.g. .s.t.a.r.|
00000150
OneDrive seems utilized the com.apple.fileutil kernel extension via kernel control sockets.
$ kextstat | grep fileutil
	161		0 0xffffff7f81773000 0x18000		0x18000		com.apple.fileutil (20.036.15) E3E63A3C-BE10-3DB3-A89F-F2313C192EB0 <6 5 3 2 1>
$ netstat -n
...
Registered kernel control modules
id			 flags		pcbcount rcvbuf	 sndbuf	 name
			 d				0				1		 8192		 8192 com.apple.fileutil.kext.stateful.ctl
			 e				0				3		 8192		 2048 com.apple.fileutil.kext.stateless.ctl
...
Yet the document is only available to Apple and OneDrive.
And as far as I know, the com.apple.fileutil kext come as early as in macOS 10.14
The similar pattern also apply to Dropbox as I rechecked Dropbox in Big Sur recently:
$ pwd
~/Dropbox
$ xattr -l 'Get Started with Dropbox.pdf'
com.apple.metadata:_kMDItemUserTags: <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><array><string>Online-only</string></array></plist>
com.dropbox.attrs:
00000000	0A 12 0A 10 9F B5 39 2F 57 E3 32 10 00 00 00 00	|......9/W.2.....|
00000010	00 00 00 05 10 E4 FF B9 82 03										|..........|
0000001a
com.dropbox.placeholder:
00000000	03 00 00 00 AC 18 A3 2B 00 00 00 00 0A 12 0A 10	|.......+........|
00000010	9F B5 39 2F 57 E3 32 10 00 00 00 00 00 00 00 05	|..9/W.2.........|
00000020	10 E4 FF B9 82 03																|......|
00000026
$ netstat -n
Registered kernel control modules
id			 flags		pcbcount rcvbuf	 sndbuf	 name
...
			 b				4				0		32768		 2048 com.apple.fsplaceholder.logging
			 c				4				1		32768		16384 com.apple.fsplaceholder.kauth
...
$ pwd
/Applications/Dropbox.app/Contents
$ strings Frameworks/python-extensions/macinfinite_native.cpython-37m-darwin.so | grep fsp
infinite_dbkext_load_fsplaceholder_kext
infinite_dbkext_unload_fsplaceholder_kext
k_infinite_kauth_fsplaceholder_kern_control_name
com.apple.fsplaceholder.kauth
load_fsplaceholder
release_fsplaceholder
$ pwd
/System/Library/Extensions/FSPlaceholder.kext/Contents/MacOS
$ strings FSPlaceholder | grep -i dropbox
com.dropbox.placeholder
.dropbox.cache
Dropbox
$ nm FSPlaceholder | grep sysctl__
U _sysctl__vfs_children
0000000000005108 D _sysctl__vfs_fsplaceholder
0000000000005260 S _sysctl__vfs_fsplaceholder_children
0000000000005210 D _sysctl__vfs_fsplaceholder_connected_clients
00000000000051a8 D _sysctl__vfs_fsplaceholder_connected_logging_clients
0000000000005158 D _sysctl__vfs_fsplaceholder_kext_version
Before we launch Dropbox.app
$ sysctl vfs.fsplaceholder
vfs.fsplaceholder.kext_version: 1.13.2
vfs.fsplaceholder.connected_logging_clients: 0
vfs.fsplaceholder.connected_clients: 0
After we launched Dropbox.app
$ sysctl vfs.fsplaceholder
vfs.fsplaceholder.kext_version: 1.13.2
vfs.fsplaceholder.connected_logging_clients: 0
vfs.fsplaceholder.connected_clients: 1
vfs.fsplaceholder.connected_clients down to zero after we closed Dropbox.app
Like before, no document at all, exclusive support for Dropbox.
So both Microsoft and Dropbox have corporation with Apple before the macOS FileProvider API is ready.
Which is unfair to many of us who used deprecated KPIs, we now cannot use FileProvider, and EndpointSecurity can't suit in our use cases.
And our customers complain about why your app is malfunctioned.
We have urged(via feedback) to speed up development of macOS FileProvider API, which Apple, disappointed us for a long time.
