I've spent some significant time looking into this, and wow, what a can of worms this is.
The error code returned when you select a StableBit DrivePool drive as the destination for app installs is pretty much completely useless. I had to break out the decompiler to understand why it's not allowing the pool to be selected as the destination for apps.
It turns out that the service that sets the destination drive checks to see whether it's running on a desktop SKU, and if it is, it tries to attach a filter driver called "filecrypt" to the selected volume. Now you might think, why would that be an issue? After all, we have a real file system registered in the system, and attaching filters to it should not be a problem. Well... Microsoft chose to hard code the file systems that "filecrypt" is allowed to attach to, right in the filter driver initialization routine.
Filecrypt will only attach to FAT, exFAT, and NTFS drivers. You'll notice ReFS is absent from that list, and that's why it can't be selected as the destination for app installs either (at least for the moment).
In addition, just to make things extra difficult, the file system check is not asking the file system driver for its capabilities. It's actually reading the driver name, and making assumptions based on that. Since you can't really have 2 drivers with the same name (i.e. NTFS and NTFS), you're pretty much stuck.
You can see this file system check in action like this: fltmc volumes
You'll notice that any pooled drives are listed as unknown file systems.
But I did say that you're pretty much stuck, and not completely stuck. Just as a test, through some clever kernel memory manipulation, I managed to convince the filter manager that we're NTFS. This is where things get even more bizarre.
The AppX deployment system apparently requires EFS (Encrypting File System) support in order to function. CoveFS can't support EFS by default because it contradicts with how StableBit DrivePool functions.
The idea behind EFS is that each file is only accessible by the account that created it. For example, if the 'Alex' user created a file on the pool, no one else (not SYSTEM, no one) can ever access the contents of that file, regardless of what the ACL file system security settings are set to. This means that background balancing and file duplication can never work with EFS encrypted files on the pool.
As far as I can tell, the motivation for requiring EFS is to "protect" the application files from the user. In other words, I think that Microsoft is trying to prevent users from having the ability to modify their own app files, on a level beyond simple ACLs. On file systems like FAT32, where ACLs are not available, that may make sense... Except that it really doesn't.
Anyone with half a brain and a command line can simply bypass the EFS encryption like this: psexec -s -i cmd
That will fire off a command prompt owned by SYSTEM. That command prompt (and any apps that you launch from it) will have full access to all of those EFS encrypted files.
I did go a bit further than this, but didn't get anything functional. I ran into some further issues with the AppXDeploymentServer.dll, where it was throwing some obscure event log error about:
"AppX Deployment operation failed for package ... The specific error text for this failure is: error 0xD0000010: While processing the request, the system failed to register the windows.integrityExtension extension due to the following error: <Error message string not found>."
"Deployment Register operation with target volume F: on ... from: (AppxManifest.xml) failed with error 0x80073CF6. "
Trying to figure out why this was crashing led to a dead end. AppXDeploymentServer.dll is protected and seems to obfuscate its stack (so a debugger can't easily see it).
I didn't want to go much further, as I've already spent a significant amount of time on this. The Internet is filled with error messages similar to this, and I suspect that it's just another layer of protection against file tampering.
One thing is for certain, this entire system is not friendly towards 3rd party file systems.