Oh - I understand - it's an orthogonal purpose: to improve the quality of normal generation. (My "flat" statement was just meant as a cheap way to save CPU time by no-oping the smooth on a known flat piece.)

Two thoughts:
1. It may make sense to keep meta extensions that improve processing speed separate from meta extensions that improve normal quality; any time we add logic to make the normals look nicer, it may conflict with all other such extensions, so knowing every extension that can change the normal will be necessary for sanity.

2. If you simplify my scheme by not special-casing all-flat geometry, I've created basically "smooth-self" and "smooth-with-parent". It turns out that you can compute that cheaply and correctly on the fly for at least a few key primitives; when building the connected mesh, a mesh is smooth-self if it has zero edges that are 'open' (meaning connected to neither a line nor another triangle). stud.dat and all groups and rect.dat correctly parse as "sealed" - rect2.dat and rect3.dat parse as unsealed.

Parsing for complex parts like animals can give false "unsealed" results, but this doesn't matter- the key is to identify that heavily used primitives like studs are entirely self-sealed and don't need to be smoothed with their parents.

This means that not only can we create a faster t-junction fixer without meta commands, but the results of the seal test could be used to generate a candidate list of parts to get the META command should we choose to implement it.

3. we've had at least two other proposals for improving normal quality besides noting flat-but-shared normals: allowing the normal to come from a higher-level primitive (specified via a meta command) and allowing explicit normals for some polygons. This makes me think that normal quality, while important, might be orthogonal to the overall algorithmic problems (e.g. given no meta commands, can we come up with decent normals quickly).

cheers
ben