Nested Markdown list renders as code block in one renderer, nested list in another

I maintain documentation that must render correctly in more than one Markdown toolchain, and nested lists are the sticking point. The same source — a - a item with a - b child indented two spaces — can produce a nested ul, a flattened continuation paragraph, or an indented pre/code block depending on the renderer, with no error reported in any of them.

My understanding is that CommonMark measures a list item's content column relative to its marker (so two-space nesting works), while renderers following older Markdown.pl conventions, such as Python-Markdown's default behavior, historically expect four-space indentation. GFM builds on CommonMark, so GitHub-style renderers accept the two-space form. I also assume tabs are unreliable here because tab-stop handling differs across parsers.

What I cannot resolve is a portable authoring rule I can enforce across contributors without knowing every downstream renderer, and how much I can trust a parser that merely claims "CommonMark conformance" when spec revisions (the 0.27–0.31 line) have tightened list rules over time.

Is four-space indentation of nested items actually sufficient and safe across CommonMark, GFM, and Markdown.pl-style renderers, or are there documented cases where it still diverges?

When a pinned parser and a current parser both claim CommonMark conformance, what is the practical way to confirm which list-indentation behavior my toolchain implements — is comparing output in a reference dingus or Babelmark considered authoritative?