When an exFAT disk is loaded through RAMDisk, any Office 2010 (C2R) program fails to load and crashes early. More specifically, it does not even begin to launch because the failing point of conflict is the underlying Application Virtualization Client (4.6.x) layer. This C2R is still used quite widely by many Office 2010 users, but does not affect MSI installed versions. So that would mostly be consumer versions of Office 2010.

Microsoft Application Virtualization Client (4.6.x) has a handful of kernel-mode drivers and therefore is quite deeply rooted into the system. This may be the source of the problem but it is difficult to determine. It ended up taking me several months to diagnose this issue because the C2R errors were not very detailed or descriptive. I did not even suspect RAMDisk until a month or so into the issue.

Now, I have narrowed it down even further:
exFAT disk mounted at boot: Failure (Office 2010 C2R fails to work)
exFAT disk mounted at logon: Success (all is well)

I had always used NTFS RAM disk loading at boot for several years, then switched over to exFAT loading at boot when RAMDisk 4.0.4 was released and that is when Office 2010 stopped working entirely. Now that I have figured out that loading the exFAT disk at logon does not cause the conflicts with Office 2010, that is a temporary workaround so that I can continue to use exFAT with RAMDisk and continue to use Office 2010.

This problem is very easy to reproduce consistently. However, I don't know if RAMDisk software is able to make code changes to avoid this conflict or not. It is very deeply rooted and difficult to get appropriate details of the crashes.

I created another RAM disk for the purpose of this testing right now. I did another exFAT disk with the Hard Disk Emulation checked as you suggested, followed by a reboot to test against Office 2010 C2R.

Unfortunately, even with Hard Disk Emulation, Office 2010 C2R still failed to launch any Office apps due to underlying App-V failure to initialize.

Microsoft isn't really caring about exFAT too much. There is a long time unresolved issue "Bug in renaming a file on exFAT" on Microsoft website.
If upper case renaming is part of your workflow you also have to use NTFS.

I had a feeling that this deep rooted bug was more to do with Office 2010 (underlying App-V) not properly supporting exFAT and therefore having some sort of low level kernel driver conflict.

I mainly use my RAMDisk for browser profile and cache and Thunderbird profile as well. So in my case, continuing to use "disk mounted on logon" is a perfectly fine solution that has been working well since I made the change. I don't necessarily need the disk to be mounted at boot time. So all is well now since logon mount works around the issue with Office 2010 C2R.

Regarding exFAT vs. NTFS:

In all of my perf testing so far, it seems that NTFS is slightly faster file system in my use case of browser cache files. I haven't been able to do a single test yet which showed exFAT being faster than NTFS. I know that SoftPerfect's own testing has shown exFAT being faster in comparison to NTFS, but those tests were large 4GB files being tested if I remember correctly. But for browser cache files being typically much smaller, NTFS has proved faster in my testing. FWIW, I have been using a relatively newer perf testing tool (https://ccsiobench.com/) which is quite nice.

ReFS:

Speaking of file systems, do you have any upcoming support for ReFS file system? Now that all Windows 10 versions support the file system and contain the relevant kernel drivers to support them, this would be great especially for testing purposes. I know that ReFS formatting is only supported on Enterprise level versions of Windows 10, but general ReFS file system support works on all. I tried to format a RAMDisk (via Hyper-V Enterprise machine) but unfortunately the formatting failed.

I have a paid licence to SoftPerfect RAMDisk and will continue to support the great development that your team does. One of the best software that I have ever purchased.

Unfortunately ReFS isn't currently on the list due to the extreme complexity of its data structures, which we have to create manually (system formatting routines are not available at the time RAM disk driver starts). At the same time there isn't a clear benefit of ReFS since NTFS serves well for almost any purpose.

Regarding exFAT vs NTFS performance, we've seen better numbers on exFAT rather than NTFS when using DiskMark. Please feel free to test in your environment and share your findings here.

That said, NTFS is an excellent system, and it's clearly stood the test of time.

I decided to run CrystalDiskMark as suggested. You are right, indeed, exFAT proved faster in comparison to NTFS in all categories. Even running the test with a smaller test size, exFAT came out on top. Very good. Further tests have continued to show exFAT being more efficient and faster so I am definitely thankful now that I made the switch to exFAT for my browser cache and Thunderbird profile. I'm not sure why that CCSIO Benchmark program shows different but I suppose the testing/benchmarking methodology is quite different between the two programs. I will stay with exFAT.

Thank you for the details regarding ReFS file system as well. It was more of a curiosity rather than a request. I figured that it was still quite new and not very much specifications to implement anyway at this stage.