The problem isn't so much that you put the closing
</pre> tag on a new line, but rather that you have two sets of
<pre> blocks with stuff in them, and you didn't write them in a way that the parser was hoping you would.
Essentially, what happens is that there's a set of regular expressions that attempt to temporarily remove raw HTML from the source prior to the Markdown syntax being parsed, and the first of these checks for something like the following:
<!-- Possibly some content -->
Where it picks up the first tag (because it isn't indented), then attempts to find the closing tag by looking first for any number of lines, followed by the closing tag preceded only by a newline (i.e. the tag is not indented). The rationale for this in the original WMD source is that it avoids catching the closing tag of nested blocks, by imposing that they are indented:
</div> <!-- This won't be considered the closing tag of the first div -->
Naturally, this isn't always how things work, so there's a more liberal
<tag>...</tag> check after that. Unfortunately in this case, the damage is already done, because the parser has decided that the opening tag of your first block matches the closing tag of your second block, and has removed everything between them from being parsed as Markdown (since content inside of raw HTML is never parsed).
Of course, when the generated HTML is inserted into the preview, your
<pre> blocks display correctly because the browser recognizes that they are how they're supposed to be. The pieces in between are still as you wrote them though, having not been parsed.
In your particular case, the most parser-friendly source would likely be the following:
Line followed by an empty line
### Section title ###
some more code
I was able to come up with a modified expression that, while still not quite as good as the server-side parser, should handle cases like this more gracefully by scoping the non-indented closing tag to the closest non-indented opening tag. This would be a replacement for the first regex in