Section 5.2 (List items) says

A list item may not contain blocks that are separated by more than one blank line. Thus, two blank lines will end a list, unless the two blanks are contained in a fenced code block.

Indented code blocks can contain multiple subsequent blank lines as well (as example 56 shows); I don't understand why the two would be handled differently here.

If there's a compelling reason for this, then it should be at least rephrased, because as it stands, the second sentence does not follow from the first.

My reasoning was as follows: One of the main motivations for
introducing the two-blanks-break-out rule in the first place was to deal
with complications raised by indented code blocks. (For example, how do
you have an indented code block immediately following a list?)

So, imagine we want the following:

1.  list item
        indented code inside item 1
        indented code block which is not part of
        the list item but whose content is indented
        four spaces (so that the whole block is indented
        eight spaces)

The two-blanks-rule allows this, but if the two blanks were
allowed to be part of the indented code block, we'd just get a
single indented code block inside the list item.

This is a rather contrived example, and perhaps this isn't likely
to come up much. So I'd be open to allowing two blank lines inside
an indented code block in a list item. Indeed, I think this would
make the spec more coherent, since the distinction between fenced
and indented code blocks is unexpected here, and the current wording:

A list item may not contain blocks that are separated by more than
one blank line.

doesn't actually tell you that two blank lines inside an indented
code block (which is after all a single block, not two blocks
separated by two blank lines) is treated differently.

Any other thoughts on this?

I like the double-blank rule very much, precisely because it fixes the "code after list" problem (here's my Meta Stack Exchange post on that issue), even though I still maintain that it's a very rare issue (in 99% of the cases, you'd want the code block as part of the list item; it's rare that you start something new with code as opposed to text).

And yes, I think the 8-space indent problem is even less likely to come up (and with fenced code blocks, there's even a reasonable workaround for this rare case), so I'd vote for consistency.

I would prefer if indented code blocks behaved the same regardless of where they are placed. So in that example, it should stay as one code block.

In general, instead of inventing weird rules that break the otherwise consistent behavior, I’d prefer to just have some kind of “block breaker” that breaks whatever block there was previously and resets the parsing process.

For example <!-- --> works well for that. I do it all the time on SO, when I want to post multiple but separated code blocks.

I would prefer if indented code blocks behaved the same regardless of where they are placed. So in that example, it should stay as one code block.

In general, instead of inventing weird rules that break the otherwise consistent behavior, I’d prefer to just have some kind of “block breaker” that breaks whatever block there was previously and resets the parsing process.

The only other container block, besides lists and list items, are block quotes. According to this spec, they already break on a single blank line. So there's no particular need for a general block breaker.

However, it is true that the two-blanks rule is a bit weird and adds quite a bit of complexity to the spec and parsers. And, with fenced code blocks, there's less of a need for it than there used to be.

It would be good to hear what others think of it.