Thanks for the feedback. I'll try to address your concerns:
I don't advocate that my filesystem would be rushed out without testing. I think a couple of years would not be unreasonable. There is also the option to integrate it with the ifdefs in place as a temporary stage. The specifics of the review, testing, and consideration for release process would be up to you and the other maintainers. For my part I expect to keep my project fork synced with ioq3 along with other tweaks and updates for at least a few years, so there isn't really a rush.
Of course no code is perfect, but the standard to improve on the existing filesystem isn't that high. People have had to take for granted that adding a lot of paks will make the game slow and unstable, and that a single bad pak can easily break the game. My filesystem can fix 99% of those problems. There are multiple tricky issues with the download support where downloads fail or go into a loop due to poorly configurated servers, and in practical usage my filesystem succeeds in connecting to a lot of servers where the old client fails. My filesystem fixes a whole host of outright and potential security, crash, and other issues.
I'm not a better programmer but I do have experience with this particular area of the code. I would help maintain if the project was integrated, since obviously I want people to have the best experience with it as possible. The new filesystem should be able to support everything the old filesystem does without needing to maintain both versions long-term.
The functionality of files.c is implemented in /code/filesystem/. The fscore is actually a separate component that can be compiled and used separately from the game. It handles the core file indexing functionality and you can think of it as sort of a library the rest of the filesystem uses, although it could be useful for other things like mapping tools as well. All the fscore files are written from scratch except fsc_md4.c and fsc_gameparse.c, which are needed for pk3 hash calculation and shader parsing, respectively.
The file structure is my best effort to separate the code into coherent parts. I personally think it is easier to work with than the old files.c, but it's hard for me to know how other people will like it.
The renderer already had some filesystem calls, but I needed to add new ones to make functional improvements. The shader selection is moved into the filesystem so shaders can be prioritized with the full range of data available to the filesystem, and so shaders and default shader images can be prioritized side by side. The filesystem only parses the name and basic structure of shaders, not what's within the brackets, so it doesn't affect functionality of any normally formatted shaders.
It's important to note the renderer can function without the extra functions and you can currently run an old renderer dll with the new filesystem without significant issues.
The two hash tables use memory differently. Not perfectly elegant solution but it works
No problem. As I said, I think I can help maintain the filesystem, so that could be a positive thing. I like the new renderer, and I think it's mutually beneficial with the filesystem. There are thousands of really good fan-made maps for quake 3, and better file handling and better graphics combined make for a very good experience.