First of all multiple versions of map-compilers may be needed. Even if a map works as intended on the latest compile may not necessarily mean that it works fine on future map-compilers.
I disagree. Generally speaking, bad/non-clean brushwork has been proven to be a problem with newer compilers. Good brushwork is not really covered by the GTKR manual, which a lot of people seems to use to create maps. Hence why I think that including multiple versions of q3map2/bspc is unnecessary. We must, however, have a good mapping manual (and the complementary tutorial) to supplant the mapping documentation which comes with the Q3 gamepack, which is highly outdated. I imagine one PDF or a small group of them might do the trick.
Furthermore a number of standard compile scripts should be available for map makers. Some that you just drag-and-drop the map file onto and then a short while later gets a pk3-file that can then be tested. Then a map-maker would not have to think about compile switches other than reporting the standard compile script that gave the wanted result.
The main difference between the compile script would properly be lightning related (floodlight for instance). Perhaps a fastvis for space maps.
A build.xml for Radiant editors should also be made with standard switches so that the bat-script have a maximum probability to work in the first go.
I highly agree on this, but there could be a complication since .bat files can be rewrote as .sh files but not the other way around because of lack of certain commands. I suppose we should also include default compile lines in the OA gamepack which aren't copies of the ones coming with the non-Free Q3 gamepack.