The only cases where you can really count on QC being involved and having meaningful input on the situation are:
2. same engine on client and server, with an extended protocol (this includes things like stuffcmd of new cvars, that is protocol too).
In general the way I extend map capabilities is to add special parsing of worldspawn on both server and client, not making any attempt to communicate the details; if the client and server have different versions of the map - or different versions of the associated .ent file - that is not the engine's problem to solve (I am aware of the fact that .ent files are used for ctf map patching on servers, and such - this is unfortunately not a supported use case for worldspawn changes).
A couple existing examples of this are how darkplaces parses the "sky" key and the "fog" key from worldspawn, rather than networking this, let alone involving qc - the qc is often not only unaware of this functionality the level designer wanted to use, but also predates the level designer wanting to use it - id1 progs.dat being the typical example, quoth progs.dat being another example.
It's rather alarming to assume that maps were made for the qc they are running on, or that the qc was made for the maps (even less likely).