Re: rendering: while marked has served us fairly well for a long time, having a look at alternate renderers is probably more fruitful, and helpfully, this is hot-swappable in JupyterLab.
jupyterlab-markup, based on markdown-it (which is also what myst emulates, for good or ill) is already capable of a quite a bit, and could be extended to support any of the above syntaxes. Therein lies the problem, of course: there is no “Jupyter Markdown” spec (handshakily, it’s GFM+MATH$… but with some mangled links), myst is extensible, pidgy does different things per release 
and the commonmark extension spec hasn’t budged in years.
The danger of this: whatever clever thing is done, at whatever level, if the renderer isn’t portable/formally defined (e.g. an ANTLR/lark grammar), a given notebook would need a static representation of the rendered HTML of itself to even be confidently shareable, much less reproducible, even if it was pleasantly authorable. In pidgy, we achieve this by taking “fancy” markdown, and emitting “boring” HTML during the REPL loop in-kernel, but one could also imagine implementing this inside a client or postprocessor… albeit with a much higher bar of requirements vs “boring” markdown.