You don't handle it in kernel space. If your FS driver segfaults then you get a kernel panic and the entire machine restarts, including all apps, therefore the apps aren't expected to handle such failures.
The "apps" wouldn't be expected to handle this failure in a microkernel OS either, only the driver process would. Since it's outside of the kernel it has a much better chance at doing so. At the very least, you can just kill the driver and restart it, which is effectively like restarting the system just without interrupting the programs that don't depend on it. This actually has been done successfully so it's not just a hypothetical benefit.
If the driver process crashes then presumably other processes have to be able to re-establish a connection and resync state.
I think the question is how many programs don't depend on the filesystem. Given that they're loaded from it, you'd presumably need to give up mmap and pre-fault all the code for even very simple programs to survive a loss of connection to the fs driver. It seems like an extreme edge case.
Firstly the driver would not expose a filesystem interface, it might expose something like a block-level interface. The filesystem would be provided by yet another process that operates over that block interface.
Secondly, mmap implies shared address space mappings, but note that the driver process doesn't have to be the owner of those mappings. If the driver restarts then the mmap process reissues any DMA commands to the faulted driver(s) to re-establish those mappings.
So now block devices can be restarted in case of faulty hardware. This might seem like kicking the can down the road a bit, but the point is to partition the statefulness into smaller, more manageable pieces that can be reused.
The filesystem process can preserve its caches and open file descriptors, and it should log mmap commands it issued in case of mmap faults as well. This is pretty robust and not so trivial to do at the kernel level where data structures are all intertwined.
