More about #2 (the crash):
I've got several instances of a func_train trundling around a loop of path_corners. Some of those path_corners also trigger a target_speaker; or in some of these cases, there's a wait at each corner, and target_delay and target_speaker entities hooked in so that a noise plays whenever the func_train "moves out" from the corner after the wait. An example with a tiny 2-corner loop:
If I rip all of the func_trains out of the map, no crash. Also no crash if I instead rip out all of the target_speakers that are triggered (directly or through a target_delay) by a func_train hitting a path_corner. So that's interesting. (?)
path_corner has targetname X, wait 4, target Y
path_corner has targetname Y, wait 0.5, target X
target_delay has targetname Y, wait 4, target (some speaker entity)
target_delay has targetname X, wait 0.5, target (some speaker entity)
As far as I know this is a legal way to use those entities. I see that the current entities.def just describes the target property of path_corner as "point to next path_corner", but at least in Q3 it could also trigger other entities (an explicit call of G_UseTargets in the ReachedTrain function). Anyway it works in Q3, but something about this trains/corners setup seems to be making QL very unhappy.
Has there been any talk in the past about QL changes to func_train or path_corner? I guess the QL gamecode (source for qagamex86.dll) hasn't been open-sourced, has it?
Since these trains are cosmetic and can't be blocked by players, I guess I can simulate the same audio behavior by using independent chains of target_delays/target_relays/target_speakers kicked off by a trigger_always, set up with the right delays so that the sound just happens to play as the train leaves each corner. A quick test shows that this doesn't crash QL. It'll be a pain in the neck though because to make the sound match up I'll have to calculate the travel time for each leg of the train's path.