There may be a third option.
It all boils down to this simple question: is Markdown code?
In the original specification by John Gruber, Markdown elements could be easily embedded in indented code blocks because the indentation itself removed the embedded elements from the Markdown syntactic space. So it was possible to write this:
# indented header level 1 that is not one, it's code
as the header here is not a header according to the current syntactic space. In the original specification there was no regionality, all the rules where valid everywhere.
The fenced code block introduce a regionality by saying: “everything between the start fence and an eventual closing fence, present or not, is code”: even if it’s valid Markdown, it’s code. In the original spec all valid Markdown stayed valid regardless of the position or the context.
I think the CommonMark spec should follow the original specification and all valid Markdown should always be valid.
As I said before, the fenced code block share a same parsing property as paragraph as it’s continuation is implicit. And I think the same closing rule as the paragraph should apply. Therefore, the solution would be to stop an unclosed fenced code block when reaching a valid Markdown element according to the current syntactic space. A fenced code block could be stopped by explicit block elements like headers, html block, or anything valid that tells us that we are not anymore in a fenced code block.
A fenced code block could not be stopped by a paragraph, so the ending fence would be necessary to distinguish the end of a fenced code block in case it is followed by a paragraph that we want to exclude from it.
This resolves all problems, align with the original spec and introduce a nice propertie: all valid Markdown elements according to the current syntactic space are always valid i.e. they are not code. It also avoids fenced code block to continue infinitely until the end of the document, which is certainly not the user intention to do so, especially if there is for example a header following. So, handling this way a fenced code block is also intuitive from a user perspective.
This introduce something else though, Markdown could not be included in fenced code block anymore unless it is indented, or “not valid”. So to make a code block with Markdown inside it, someone would have to either use the indented code block or the
<pre><code># Valid markdown header</pre></code>
html tags. But I think this limitation is small and in fact: the new rule fixes the conceptual case against fenced code block. More importantly, the reference specification can continue with the streamed parsing strategy already used, no backtracking is introduced, compatibility with other implementations is kept in most cases unless fenced code block are used to enclose valid Markdown in the current context and the parsing philosophy gap with the original specification is eliminated.