Got it. So, if I understand correctly, there have been no efforts to introduce dynamic memory management to the engines that would, in theory, remove the need to have hardcoded limits to its capabilities (however high they may be)? I’m asking this just to have my thoughts in order before diving into FTE / spasm / etc source code for answers... 

efforts to introduce dynamic memory management to the engines that would, in theory, remove the need to have hardcoded limits

I recall some talk of this in engine threads here, but I don't know to what extent this has been implemented (if at all). I'm at the limits of my knowledge on the subject here, so best check with engine chappos like spike, ericw, metlslime etc. 

the vanilla behaviour is for map lumps to be consecutively allocated onto the hunk.
this means you don't pay any memory costs for unused faces or whatever.
it also means that the engine has no real need to enforce any of those max_map_* limits, it only has the hunk size to worry about.

there are some exceptions though, like max_map_leafs that uses various statically sized buffers around the engine, but since Sepulcher neither FTE nor QuakeSpasm have any of those MAX_MAP_* limits remaining (ignoring MAX_MAP_HULLS_hulls which is part of the file format so doesn't really count).

Note that file format limits are not always as strict as they first seem. A few limits have been increased by just redefining variables as unsigned, thereby doubling the limit. The most creative expression of this is the max_leafs and max_nodes limits, that still need to share a 16bit index, resulting in some interesting logic to decide whether a node's child is a leaf or a node instead of just checking the sign.
The progs.dat format has a similar tweak to double the numpr_globals limit, while being careful to not break statements that do not refer to globals.

Either way, just because you CAN have large maps doesn't mean that you should. Or to put that another way, I don't remember to hit quicksave often enough. 

Some engines have dynamic allocation, but not all. 

(And fails) 

The artistic skills employed in the Q2 models are much superior

I'm talking about the art, not the file format.

In Q1 there's the squished dead fish head, the badly offset knight skin, the badly bent knight sword in one frame of its animations, the lack of a vore idle pose, stuff like that.

It's not about technical limitations. It's more likely about lack of time to correct mistakes before they released the game.

For example, Hexen II models were created with vastly superior skills, despite using the same format. 

The Hexen 2 models are better yes, but still have crap stuff - there's some cat-headed man thing whose legs collapse like squished cardboard boxes during his run animation for example. 

in general, if you want to study great low-poly models, looking at stuff from the 90s might not be the best strategy.

In modern times, ultra-low polycounts are still used for some mobile games, and can be found in some indie games and whatnot for stylistic reasons, if you dig around you can find some incredible artistry on display in this area. 

Rareware N64 games also had great animations with incredibly low polycounts. Banjo & Kazooie, Conker's Bad Fur Day, and so on.

Turok 2 also has great animations, despite the wonky physics.

Unreal may have had skeletal animations, but they were too floaty and IMO inferior to Q1 model animations. Unreal II and UT fixed that. 

While talking of Q1 models. I've got this strange habbit noone could explain yet.

As a fan of Q1 models I was searching for long for the SailorMoon models of Usaki. I finally found them and tried to convert them from Q2 to Q1. This worked but the texture file got lost. Normally I split up a base model, import it again as dxf and start texturing again.
A lot of work, but I don't mind.

Then I thought of Noesis, that would help me out. No, not the slightest idea how to add the skin file.
Then I found Qwalk, and yes, there were my models, without weapon but allright, that can be fixed with merging.

But my question, these models grew up to something of 3Mb, quite large. I experienced when loading them up in Quark4.07 and saving them would deminish them back to 750kb.
Only warning is "Some vertices have the same front and back side, you will get strange effects" but in game there is no sign of them.

What's the reason of this warning and would it be destructive. 

QuArK sucks for modeling. It splits the vertices shared between the front and the back sides of the texture, making the model filesize larger and killing the gouraud shading across front/back seams.

The 3MB thing, however, seems to be an issue with triangles having both a backside and a frontside.

(triangle backside&frontside isn't the same thing as texture backside&frontside) 

thanks for your answer mankrip.

I'm allready glad I catched the models with Qwalk. Sad I don't understand the manual of Noesis. It seems there are not many Q1 model converters.

Yes, QaArK ain't the best model studio.
Got to row with the peddles there are at hand. 

With Oculus Quest out in the field, I’m wondering, given the team behind the hardware and SDK, what would happen if somebody like me or you guys attempted to publish one of our engines to the Oculus Store 😂 

Create a thread of your own where you can rant about otr and post drunken burps one title at a time while the other threads on this board remain clean and on-topic!