I think Sirbomber and TH300 have the right implementation idea for a steady ore mod. Change the interface into the game engine in just one place, rather than update each level DLL.
You could possibly update the game setup window to add a new checkbox. That's starting to be a lot of work though. Adding options to the interface also means you'd need support in the network layer to send the new options to other clients. It also opens the door to adding a lot of simple options that could quickly clutter up the interface.
Allowing the game type to be selected after creation would be very nice. I was thinking of doing that early on in the NetFix patch, but then I realized that's a lot of extra work, and just re-using the existing pre-game window would save a heck of a lot of time and effort. If I'd held up the release to do that part too, people might never have seen the patch.
As stated, having steady ore does not fix unfair map layouts. Making symmetric multiplayer maps with consistent ore as a design feature might be the best way to allow fair games. It's probably more work than a simple mod to ignore beacon creation parameters and just set them all to zero though.
I think leeor_net might be right about effort though. If we'd taken the reverse engineering and patching effort we've put into the game already, and instead spent that effort on rewriting the game, we'd probably have a new game by now. But the problem with that is the long delayed gratification where there is little to see immediately, which tends to kill enthusiasm to keep up with a project.
Ignoring the recreation idea, and continuing with the reversing and patching concept....
I had given some thought to automating recreating existing levels. Basically create a new executable file that mimics the same exports as Outpost2.exe, and have it load the level DLLs and call the appropriate functions. The fake exported game engine functions would be simple stubs that would record the parameters they were called with. The recorded parameters could be emitted as a data structure describing the level, or perhaps as source code to make equivalent calls. You'd have to special case calls for random number generation though. Treat calls to rand like a branch point, and re-run level setup, stepping through the possible return values for rand, and accumulating the data. The idea was mostly for initial level setup, but it could be extended a little for run time changes, such as disaster creation. Once level setup was done, there should be a list of trigger callbacks available, which could be used to record information on disaster creation functions. At this point though, the project idea starts seeming a bit big. The calls to rand, and run time modifications really muddy the waters. But, the bulk of level code is in the initial game setup, not the run time modifications.