I've been having a brief poke around the source of ADFS, FileCore and FileSwitch.
Firstly there's a serious documentation need. All the documentation is in little text files scattered around - ideally it needs someone writing a basic overview of what happens where. Secondly FileCore and FileSwitch are inherently harder to understand (for me, anyway) because they do lots of structure twiddling which is harder to understand in assembler.
Retaining ADFS as-is for its floppy support (on any machines that still have drives). All the floppy foibles take up a fair amount of code and I think it's best left alone.
Re-implementing the hard drive support as a new IDEFS (davehigton and I had a go in 1997 - it wasn't too hard to get something working, the messy bit is coping with all the variations in drives out there)
Bin RAMFS. Fix bugs in Memphis and use that instead.
A new interface between block drivers and filing systems, with a FileCore 'personality' for compatibility. This might do disc partitions too.
FileCore retained as-is, for supporting existing drives, but accessed through the new interface
A module for a new disc format (FAT? NTFS? ext3?). If it can work on an extended image filing system API, so much the better (but would have to be reentrant)
Lower priority: Rewrite HForm into a cross-platform FileCore filesystem generator - maybe plug it into acorn-fdisk that already exists.
Then it gets messy. FileSwitch is more closely tied in with the kernel, and there's no nice list of tie-in assumptions in the source as there is for ADFS. I'm not convinced rewriting FileSwitch would help - you'd have to rewrite bits of the kernel too. Extending to 64 bit addressing would be a must, perhaps at the same time simplifying the API and putting the old one in a 'personality' module for compatibility. Are there any other problems with FileSwitch other than the 32 bit file size issue? Could they be solved by helper modules intercepting calls between FileSwitch and the lower layers in the stack?