An interesting idea just popped into my head, as a combination of my explorations through the dom preprocessor and my attempt at deferring editsection replacement till after parsing is done so that skins can modify the markup used in an editsection link in a skin-specific way without breaking things, and so that we can stop fragmenting the parser cache by user language just for edit section links.
A postprocessor. It would be quite interesting if instead of html we started outputting something like this in our parser output: <root><html><p>foo</p><h2></html><editsection page="Foo" section="1">bar</editsection><html>bar</h2><p>baz</p><h2></html><choose><option><html><p>foo</p></html></option><option><html><p>bar</p></html></option><option><html><p>baz</p></html></option></choose></root> ((don't get scarred off by all the entities, this is nothing new, try looking at a preprocess-xml cache entry))
Course this is a Postprocessor_DOM oriented look, like Preprocessor_Hash we'd have a Postprocessor_Hash and it would store a different format like we already do with Preprocessor_Hash (serialized?).
The idea being the creation of new markers that aren't 100% parsed but are outputted in a easy to deserialize format and finish parsing with minimal work and extensions can output and have a postprocessor hook expand later on. In essence the idea here is two fold. Firstly things like the <editsection page="Foo" section="1">bar</editsection> I tried to introduce now is no longer a hack. And we can try to start deferring minimal processing cost things which fragment the parser cache if they aren't needed. Ideally in the future if something like {{int:asdf}} isn't used in a [[]] or in a parser function and is just a base level bit of display isolated from the rest of the WikiText we might be able to output it in a way that we don't have to fragment the cache by user lang but can still output the message in the user's lang by deferring it. And as a big extra bonus, think of the RandomSelection extension. Right now extensions like RandomSelection end up disabling the entire parser cache for a page, just so they can output a random one of a series of options. With a postprocessor they could instead craft partially parsed output where all the normal wikitext is still parsed, but all the options given in the source text are outputted and the postprocessor handles the actual random selection on each page view, only outputting one of the three html nodes. Likewise we might be able to implement "Welcome {{USERNAME}}!" without fragmenting the cache by user or having to disable it.
The key being that we get things as variable as complete randomness, at the level of re-executing that randomness on each page view, yet have barely any more processing to do than we did before. (like the rest of the ui that isn't part of the page content)