This really doesn't sound like the kind of stuff that can easily be done.

Any particular reason you think so? Seems to me they can have something like

map* preload[3];
for (int i = 0; i < 3; i++){
load_map_in_thread(mapname[i], &preload[i]);
}
..later..
map = preload[chosen_map];

Simplified logic of course but in practice not that much more complex.

What's the big deal with having a small pause between matches? If anything, longer pauses should be encouraged. Plus, I don't think the way QL servers are rigged up would allow this to be easily implemented.

but in practice not that much more complex

Do you say that after examination of Q3's source code?

I say that it doesn't sound easy to do because it's certainly not something id tech 3's devs had in mind when they programmed it. Maps are likely to be tightly bound to rendering, for instance. Or deeply integrated into a long process involving a lot of other stuff.

That may not be the case, of course, but that multi-map loading idea seems so much out-of-touch with an engine of that era that I find it hard to believe they would have chosen an architecture making implementing that (or touching it in any way) easy. Damn, that's one long sentence. Anyway, without delving into the actual code it's all hypothesis for both of us. But I'm the pessimistic kind of guy.

You are absolutely right, implementing this suggestion in q3 engine would be a complete nightmare. I suggest OP looks at the q3 code and sees what happens between maps, and how memory allocation is done.

What about people with slow PC? For some, loading just one map takes 10 seconds, so loading 3 would take 30s. Now will it abort loading once the map was chosen and try loading the one picked? Or what?

In that case there are two options

1. load the maps sequentially. for slow computers if the 3rd map is unloaded by the time the choice is made then the user still has to wait and nothing is gained. The downside is that the first map is still being loaded and cannot be aborted before the chosen map is loaded, but hopefully this is not too long of a wait. The upside is if the first map is chosen and is loaded then the wait time is now 0 instead of 10 seconds.

2. load maps in threads and kill the threads if they are still loading when a the 'choose a map' time has reached 0. this is much trickier because it involves the loading threads to constantly check for a global 'should I quit' flag and if so clean up appropriately.

no need to load 3xtimes the required into ram, if 3-10sec is not long enough to warrent this change imo.