Check out the rerelease thread: https://www.celephais.net/board/view_thread.php?id=62088

There’s an example implementation of an md5 renderer that mh posted there. 

I've written sample MD5 renderers/animators in both GLQuake (FitzQuake, actually) and Software Quake: https://github.com/mhQuake/MD5Stuff

I won't pretend they're perfect or optimal, but they are fully functional (so far as the Quake rerelease assets are concerned) and can serve as a basis for anybody else who wishes to integrate MD5 support to their engine without having to start from scratch. 

To add to my previous post. There is this mdl importer/exporter for blender 2.8+

https://github.com/victorfeitosa/quake-hexen2-mdl-export-import

I've successfully managed to import a quake rerelease md5 model and it's animations in blender 2.9 and convert it to an mdl.

Maybe I can drop these in the progs folder and run one of the quake engines (if the frame animations match one to one... which they should?) 

The frame animations do match one-to-one, with the sole exception being that there are some pickups that have two frames in the MD5 whereas the original MDL only had one.

I haven't been able to determine why.

But otherwise, I did go through the whole process of comparing every single model's frame count with the originals.

I believe that the re-release QC has recently had a GPL release so it should be possible to investigate further, check the animation code and frame definitions, and even figure out what that pesky extra frame in those pickups is.

(Yes: available here: https://github.com/id-Software/quake-rerelease-qc - I'm a big advocate of actually reading the original code where it's available, rather than try to reverse engineer and make mistakes.)

Down-converting MD5s to MDLs seems to me to defeat the whole purpose; it would have been much nicer to see wider uptake of MD5 support in source ports, and I'm at a loss as to why it didn't happen. 

Looking through the quakespasm source code the alias models and the mdl data are very strongly coupled. Models are loaded into the hunk memory. Since the the textures are also in the model even the texture loader is an mdl parser.

I'm working on decoupling the data and have a have somewhat working code, but nothing uploaded to git yet. Will keep you posted. 

That's quite similar to how the original ID code is.

There's actually a lot of data in the MDL that can be discarded once you load it into buffer objects, as it's not actually used any more, and the in-memory format for a reasonably modern renderer can be quite slim. It does complicate if you want to coexist a modern and old renderer in the same engine, though. I can't remember if QS does that.

The MDL format is parsed sequentially with each data lump immediately following the previous, and you don't really know how large a data lump is going to be, or how many of most types of data (frames, vertices, skins, etc) you're going to have until after you've parsed it. That does make it a bit of a pain to deal with, but it's typical of Quake's development where the rush to get everything done led to some suboptimal initial decisions sticking. Also the need to run on an 8mb DOS machine without virtual memory obviously imposed a lot of technical constraints that would just disappear within as short a time as a year later.