First, you’re using the wrong kind of intuition. Markdown and CommonMark aren’t looking at this from a parser’s perspective, but from that of the human eye. Second, it’s wrong to call an unclosed fence block “auto-closing”. The idea here is not to make closing fences optional, but to gracefully handle the situation when a closing fence is missing.
To illustrate my first point:
More precisely both this input 1 (no final newline):
```
aaa
and this input 1 (with a final newline)
```
aaa
Yields the same rendering:
<pre><code>aaa
</code></pre>
That’s because both of those look exactly the same to the human eye in any plain text editor.
While fencing the same content explicitely 1
```
aaa
```
```
aaa
```
Yields different renderings:
<pre><code>aaa
</code></pre>
<pre><code>aaa
</code></pre>
Because these do not look the same to the human eye. You can see a blank line in the second case.
So I guess, given the above, a single blank line is ignored at the end of input ?
Not really it seems, in the reference implementeations a final blank line is not ignored, only a final empty line seem to be. That is "```\n\n "
2 (two final spaces) gives:
<pre><code>
</code></pre>
Which has two lines and the final one two spaces.
I think this is a flaw, as to the human eye the plain text looks identical to "```\n"
, and ideally it should be corrected, but I don’t think it’s a priority because it’s a flaw in CommonMark’s attempt to gracefully handle flawed input (missing closing fence). The plain text author should use a closing fence to make explicit their intent with regard to trailing blank lines in the code, or the lack thereof.