Playing in Quakespasm with patch 2.2 installed,
I experienced this:

http://www.quaketastic.com/files/starkmon_quoth22patch.dem

Gameplay-wise this leads to a situation where the player can only proceed by an extremely well-timed and precise jump(or a trickjump),
and he gets only one chance as failure means death in lava.

As I later understood from a couple of demos,
this is what should happen:

http://www.quaketastic.com/files/starkmon_quoth2.dem

After this, I deleted pak2.pak (the patch)
from the quoth directory, and things were
fine as in the latter demo.

Long story short: the pak2 file seems to change
the door from being closed to being open. 

Thanks to the magic of "git bisect" I've found the change in the code which caused this bug, which is half the battle. Working out how the change has such a strange effect is still in progress...

The change is another conflict born of balancing Quoth compatibility with vanilla Quake and compatibility with her own maps. At some point, Quoth made the spawn sequence for func_trains about 0.5 seconds slower. This was necessary for cloning trains, but breaks some vanilla maps. 2.2 tried to split the difference, by only running slower spawns on trains that use the features that demanded it, while putting other trains back at full speed. Evidently this map relied on the slow spawn in a way I don't yet understand. 

It appears that there's a race condition in this map. Gonna post it mostly to gather my thoughts, and maybe check with Ricky I'm on the right lines here...

The delay I talk about above is how long it takes for the train to be teleported to its first waypoint. Entities in the map spawn in list order, so if the train is earlier than the waypoint doesn't exist during the train spawn-function. The standard practice in vanilla Quake is to wait 0.1 seconds before teleporting the train to its waypoint. This happens on the second server frame, before anything is drawn or can be noticed.

In Quoth prior to 2.2, this delay was increased to 0.6 seconds, which made out of place trains briefly visible at the start of the map, and caused some items to fall off platforms (but ensured that cloned platforms work correctly). In 2.2 this delay returned to 0.1 seconds for any platform which doesn't have clones or "smoothed movement", to fix those glitches.

To understand the bug in this map, it's worth reflecting on where the platform is before it gets teleported - it's in limbo wherever it was placed by the mapper. The other crucial factor here is a trigger_once placed in this particular map, which fires almost immediately upon the map starting and targets the train.

In Quoth 2.0: The trigger_once targets the train before it has been teleported to its first waypoint, owing to the larger than normal delay applied in this version. This has the effect of cancelling the scheduled teleport, which would normally be disastrous!

However, things manage to sort themselves out, because triggering the train causes it to travel from its limbo position to the first waypoint (the closed position). That's more-or-less equivalent to the teleport code, especially as the player can't get there fast enough to see it happen.

In Quoth 2.2: This time round, the teleport code wins the race, and by the time the train is triggered, it's already taken up the closed position. The result is that the trigger_once now opens the door!

So it's a bit like the apsp1 rotation glitch from a few months back. The map has some cruft which used to be benign, but is now poisonous. Since there's no way to distinguish in code between this situation and genuine intent to immediately trigger a train on map start, any fix will need to be a shim applied to this map. I'm gonna sleep on exactly what that fix should be... 

So it's a she!

Preach, thank you very much for your thorough investigation
and sharing your thoughts.

I apologize for the title 'Quoth 2.2 bug?'.

If I understand your posts correctly, parts of the map
rely on bits of the Quoth 2.1 code to function as intended.
These bits of the code have been changed for Quoth 2.2.
In this particular case this makes a difference which is
specific to this map. 

I consider any case where we have regression of function in later versions of Quoth to be a bug, regardless of the genesis. Writing out exactly how it happened is just a way to figure out big the scope is, and to hopefully avoid it happening again. The bug here doesn't look like it would be replicated in other maps going forward, so I don't think I need to think about reverting the change entirely in the mod.

Instead I think the best thing would be to apply a shim to this map. The shims in Quoth are actually a well kept secret I'll share here. When I discover this kind of conflict, where a generally beneficial global change causes a particular map to break, I add a special exception to that map rather than revert the change. This is called a shim, and there are two bits:

The first bit is the identification of the map which needs the fix. I create a "fingerprint" of the map, based on the fields of the world entity, so matching based on the model, wad, message, worldtype etc. This avoids the potential pitfall of just using the bsp name: two maps might use the same name. It also means mappers who want to release an updated version of their map have an easy way to opt out of the shim - just change the map title in the message field somehow, like adding "v2" or a trailing space.

Then the fix comes afterwards. I try to ensure that the actual fixing is only in a single function in the code, so it's easy to keep track of and doesn't get accidentally deleted when things are rewritten. In this particular case, the easiest way to fix this map is just to put the delay back to 0.6 seconds. I've uploaded a tweaked 2.2 patch with this change at
http://www.quaketastic.com/files/single_player/mods/quoth2pt2patch.zip

Not gonna bump the version number for it, but give it a try and make sure it fixes things! 

Thank you for the fix(shim).

Here's a demo with the new pak2.pak:

skill 2, 210/210 kills, 0/6 secrets

http://www.quaketastic.com/files/demos/starkmon_quoth2.2new.dem.zip 

Good stuff. Hey Ricky, can I add this map to the map packs page on the Quoth site? I packaged it up to do the testing on this patch... 

Yeah of course Preach! That's awesome :)