Hey @codinghorror, re. table syntax specifically here’s the relevant discussion: https://talk.commonmark.org/t/parsing-strategy-for-tables/2027 , I came up with an interpretation of the spec that at least put my own mind at ease re backslash-escaping in https://talk.commonmark.org/t/parsing-strategy-for-tables/2027/7 , this thread is pretty old and I haven’t actively thought about the issue since then so if you have a more specific question please ask away 
Re (composable) extensions, it’s a thorny subject One interesting question is whether one wants to solve the problem of composing extensions from multiple sources, as the parsing process requires knowledge of whether a given node type in the AST can be contained by / contain another node type.
In any case, guaranteeing that any extension is compatible with any other one is not feasible, as two extensions may want to interpret the same character for two different purposes. All the extension system could strive for is detecting such conflicts at runtime, my extension system doesn’t implement that, but as syntax extensions are expected to register special characters it might be implementable.
The more pragmatic approach, which is in effect what github uses my extension system for, is to consider that extensions can only be used as part of a “distribution”, ie you have the core implementation and a finite set of syntax extensions, which know about each other at compile-time.