ZDoom

This is surely not intended behavior - but the entire model interpolation code was taken from Skulltag a long time ago and has several design issues. It is also something I'd rather not touch if it can be avoided...

This should probably be noted on the MODELDEF wiki page, then. When using two models with the same frame numbers, it's not really a big issue, but when combining two models with different frame ranges, at that point it's easier to create a script that takes two text files and outputs the correct tangled up file. Though, when dealing with longer animations or multiple models, it's better to have some automated solution anyway instead of typing stuff out manually.
Would this be better suited as a feature suggestion, or would the way MODELDEF is parsed make this addition not worth the hassle to implement?

This is normal behavior. With multiple models, you are supposed to "interweave" the FrameIndex lines for all models. If one model should be not render for a particular frame, give it a frame index of -1.

Model MultiBroken {
	Model 0 "zero.md3"
	Model 1 "one.md3"	
	FrameIndex BLAH A 0 0
	FrameIndex BLAH B 0 1
	FrameIndex BLAH C 0 2
	FrameIndex BLAH D 0 3
	FrameIndex BLAH A 1 0
	FrameIndex BLAH B 1 1
	FrameIndex BLAH C 1 2
	FrameIndex BLAH D 1 3
}

Model MultiWorking {
	Model 0 "zero.md3"
	Model 1 "one.md3"	
	FrameIndex BLAH A 0 0
	FrameIndex BLAH A 1 0
	FrameIndex BLAH B 0 1
	FrameIndex BLAH B 1 1
	FrameIndex BLAH C 0 2
	FrameIndex BLAH C 1 2
	FrameIndex BLAH D 0 3
	FrameIndex BLAH D 1 3
}

I'm not sure if this is actually a bug or an undocumented MODELDEF limitation, but here goes:
When specifying multiple model files in one Model block and using them both for animation, if the animation frames are specified for one model first entirely, then for another model entirely, only the latter model is actually animated. The FrameIndex lines have to be specified consecutively for each sprite frame instead.
For instance, this makes only the Model 1 actually be animated, Model 0 stays still, stuck on the first frame. If instead Model 1's frames are listed first, then Model 0's, only Model 0 is animated.
[code]Model MultiBroken {
Model 0 "zero.md3"
Model 1 "one.md3"
FrameIndex BLAH A 0 0
FrameIndex BLAH B 0 1
FrameIndex BLAH C 0 2
FrameIndex BLAH D 0 3
FrameIndex BLAH A 1 0
FrameIndex BLAH B 1 1
FrameIndex BLAH C 1 2
FrameIndex BLAH D 1 3
}[/code]
To animate both models properly, it is necessary to "interweave" the FrameIndex lines like this:
[code]Model MultiWorking {
Model 0 "zero.md3"
Model 1 "one.md3"
FrameIndex BLAH A 0 0
FrameIndex BLAH A 1 0
FrameIndex BLAH B 0 1
FrameIndex BLAH B 1 1
FrameIndex BLAH C 0 2
FrameIndex BLAH C 1 2
FrameIndex BLAH D 0 3
FrameIndex BLAH D 1 3
}[/code]
As far as I can tell, the order doesn't matter here. Also I haven't tried this out with Frame as I don't use MD2s. I've attempted to instead specify two Model blocks with the same name, one containing the first model, the other containing the other model, a little bit what the multi-texture example looks like on the wiki. However, only the latter defined model then shows up in-game at all.

Attached is a file that has two models used in three model definitions, two function improperly, one functions properly, and they can be viewed in an example map.