I can imagine other interesting use cases. fat32 over the network, for example: so you can e.g. plug in a USB device into some legacy hardware, and when it does a directory read, the device lies to the host about what's inside, only retrieving the bytes over the air during a file read operation.

I think the hard part is that if the "disk" is mounted, the FAT would be in memory on Windows, so it's very hard to put in a file from "outside", because Windows will probably never re-read the FAT from the disk and will never see that file.

Why can't they keep a fat32 driver around and mount it like they always have?

The data partition used to be FAT32 and plugging the Android into USB with the mass storage option would unmount the partition and then the Android emulates a USB mass storage device to expose the block-level contents of the partition to the host computer. Note that this couldn't be done with the system partition, since the Android system itself is running on it; and even if it was unmountable, the filesystem would be a Linux one like ext3 or ext4, making it unreadable to a Windows host. In the newer versions, they combined the two partitions into one with a Linux filesystem, so there would no longer be a separate data partition to unmount from the Android and mount on the host.

The idea I'm proposing is to turn VVFAT or an equivalent idea into a kernel module that treats the data directory --- or indeed any --- directory on the Android, including the system one, as the "host" since it has a filesystem-application interface on one side that just uses the normal filesystem calls, and expose the virtual FAT filesystem over USB mass storage on the other side.

Without knowing how QEMU does it, I'm guessing writes onto the emulated fat32 partition inside QEMU get caught by their software, and QEMU talks to Windows and says "Hello Windows, I would like to store this data as a file in this directory.". The directory can probably be on an NTFS disk or even Samba mount?

If a phone is "mounted" as FAT32, the writes from Windows should be intercepted by the driver and it would create Linux filesystem calls to create/write files. If an Android app decides to write onto that partition, there needs to be a program running on the Windows side to tell Windows' filesystem driver "Hey I'm going to create this file". Otherwise Windows will never see that file.

(I'm just guessing here, maybe there is a function to re-read the FAT?)

Oh, I was thinking about this the wrong way -- I had read it as Android's ability to mount USB OTG mass storage devices plugged into the phone.

I agree with you, if the internal filesystem can't be mounted as a filesystem on most PCs then there should be some sort of virtual/emulation layer.