I see your point on how preprocessors can still be of use.
Well at the very least you can see this as a general good practice outline for preprocessor handling in such a way that there is a known way for commonmark to gracefully degrade the content if not handled by a preprocessor (or extension, etc…).
But these are just implementation issues. The core thing is really just to encourage portability, and graceful degradation of extensions. So for me, at the very least, there needs to be an agreement on how a preprocessor should be expected to locate their content in a best practice manner. Which if using your example, but with my concept would be like this (Though I would encourage using ``` only for falling back as code instead, to reduce preprocessor complexity) :
... in normal _CommonMark_ text here, but now:
~~~~!Z
%%Z
X == Y %x Z
%%
~~~~
Back in _CommonMark_
The ! is to make it clear to the preprocessor that it is actually for it to process, and not just a Z code snippet for some Z tutorial.
The benefit to coming to an agreement is threefold. Reduced preprocessor complexity, increased portability and graceful degradation.
How does various implementation handle processing the extension is up for implementation. Not our problem. Just making sure that the cruft of other language syntax doesn’t infect and force us to have hacks on commonmark in a fews years (because everyone is already using such hypothetical extention) is more important however.
Elaborated: Fenced Block Types, Generic Extension/Webcomponents, and fallback handling