Haha, YES, second that, although maybe I'm missing something but I sometimes wonder why people continue with MD5 for their custom forks instead of adding support for FBX, I mean I understand if you're using D3 content of course so you'd still want to keep support for it but I mean adding additional formats. Maybe FBX is a mess? There's an open source library that can use FBX (which has morphs, among a bunch of other things) and if I'm not mistaken is supported by a very wide range of programs but anyway back to the point...
FBX is not geared toward real-time rendering. It's an exchange format and it's used in all engine as that. FBX gets transformed by modern engines into internal format. So technically if Doom 3 used FBX, it would internally convert into MD5 anyway. The whole reason behind engine companies jumping on board with FBX is to have no headaches supporting exporters for multiple 3D apps.
So if the engine doesn't support morphs internally, then even with FBX it wouldn't be possible to have them.
Alembic format is what you want for morphs. However, Blender doesn't have support for it and won't have import/export for it in the nearest future.
There is Lightwave MDD format that does morphs, but no game engine have ever used it. Maybe it's inefficient for real-time rendering, maybe there are other reasons why, I don't know. Blender supports export/import into MDD, so I figured that would be a viable alternative.
Another way to go is to have multiframe ASE (no specs, no exporter at this time for internal storage of frames) with external frames (so 1000 frames will get you 1000 ASE files). Doom 3 BFG could binarize/compress all frames into one binary model. It wouldn't work with old Doom 3 because straight forward morph anim models eat a lot of RAM (and most likely VRAM).