There's plans from Baker to de-couple the physics from the refresh rate so that these weird glitches don't happen.
Not sure when he's planning on doing this but it will probably take some time before it happens.
I've personally stopped playing at 144hz since I was made aware of the bug and I am honestly used to 72fps again. I'll bump it back up when it's fixed. 

It breaks my heart I re-worked a kick-ass part of a map because I was so ill-informed about this but I didn't want to release something that would randomly kill players. I hope Baker can get this to work. 

The usual engine caps framerates above 72.
Result is you get damage from being elevated by a plat/door. (Dont ask why, thats above the topic for now)
Try FTE-Quake from spike. It does support "pixelvision" and all the other features we love. Plus a ton of functions you'll never see with QS or FitzMarkV or the like.

Never use DP ever.

Thats my best bet for a future engine.

vQuake is another option to try, idk if it supports the latest AD maps.
But its written for the new Vulkan (API), which should get more attention in the future. Or not. 

It is an annoying issue isn't it?

FTEQW and DarkPlaces are completely immune to this issue.

There is about nothing FTE can't do and it is very faithful. 

Thank gents. I was going to check out vkQuake but it's a fork of QS so may have the same issue. But as for as the future-proofing it's a great step. 

http://nquake.com 

vkQuake is going to have the same issues.

It is just a different rendering pipeline, which has nothing to do with any of this.

It's a physics/clock issue. 

related insideqc threads:
Is vid_vsync wrong?
Framerate-independent physics

One thing to note is that, if you implement it by locking the server framerate at 72fps, and then lerping between the last 2 server frames to generate the high fps client's view, this adds ~14ms of lag to the whole game. (at the moment when a new frame arrives from the server, you're going to be rendering the last frame. correct me if that is wrong)

I also want to note how old and problematic Wally and TexMex are. They work but how long will it be before they are obsolete?
This is true, the wad format is really simple though. though it is surprising there is no "take all images in the current directory and pack them into a .wad" tool already? 

with opengl, you can change the vsync interval so that it vsyncs every other frame, that would mean that they'd scale to decent monitors even without fixing the underlying physics (which also means avoiding breaking the 'wait' console command).
that said, vsync has its own lag, and in my experience its smoother to use cl_maxfps or whatever instead of vsync as implemented by nvidia's opengl driver (d3d or single-threaded vulkan don't have the smoothness issue, though fte seems to be able to acquire about 10% more backbuffers than it should when device queue stuff is offloaded to a worker thread).
@ericw, what you're forgetting is that thanks to interpolation, many things in the game are already up to 100ms behind. more video frames means it'll actually be closer to current.

Regarding wads, what I want to see is editors/qbsps that just directly use pcx/tga/png (with some vague shader-like scripts to provide stuff like phong angles and rescaling[so engines could directly use the same high-res textures]. I'm not saying that engines should need to read these scripts, just that I think it would be a nicer way to get per-surface stuff than creating entire func_details for a single face).
the problem with that is politics, of course. 

re: politics

Much the way the ISO works couldn't we get all the brightest, active minds in the Quake source port scene to "meet" and agree to standards moving forward? Perhaps a "lowest common denominator" standard engine architecture could be agreed upon and followed by all active developers and then engines could diverge off as long as they have these features available to the end user? 

couldn't we get all the brightest, active minds in the Quake source port scene to "meet" and agree to standards moving forward?

This has been tried and failed so many times that it's long since gone beyond being funny and is now orbiting a black planet fuelled by the crushed hopes and dreams of a small child.

We tried it, it didn't work, because everybody has their own ideas and sooner or later (and most likely sooner) it just collapses.

Then we tried it again and it failed again. Repeat to fade.

That's classic design-by-committee.

What does work is when one person pushes something forward in a way that's easy for others to pick up. That's how we got LIT files, it's how we got standardized fog, it's how we got BSP2. 

I don't know how it compares to Wally and TexMex, but in 2006 FrikaC made FImg, http://www.insideqc.com/frikbot/fimg/fimg_v02.zip

You can read the initial thread here,
http://forums.insideqc.com/viewtopic.php?p=2916

That thread has old links on it to inside3d which is no longer up.