Resolve when a block delimiter acts as an interrupting line
While drafting the outline for the specification, we identified the concept of an interrupting line. An interrupting line is a line that, when directly adjacent to a preceding paragraph (and some other cases, such as a list item without a list continuation), implicitly ends that block and transitions to the start of a new block.
In the draft outline, there's a statement that only a closing block delimiter is an interrupting line (hence it's promoted to an interrupting line when inside a delimited block). However, upon further investigation, we've determined that in both Asciidoctor and its predecessor, any block delimiter is an interrupting line (assuming we ignore setext headings). But clearly there was an instinct to change the rule that is worth exploring.
The question we need to resolve is whether any block delimiter should be an interrupting line (just like the block attribute line), or whether it should depend on context. If we want to be strictly compliant with the initial contribution, we would keep the existing behavior. But probably the best argument for always treating it as an interrupting line is that it makes the AsciiDoc syntax more context-free). By making it depend on the context, it puts reliance on a semantic predicate to consult the state of the parser. Not having to do that would get rid of one semantic predicate. However, it's unlikely we can eliminate the use of semantic predicates to process a block delimiter since one is still needed to determine whether the block delimiter is opening or closing a block.
If we decide to define a block delimiter as always being an interrupting line, keep in mind that it's still possible to escape it (meaning make it non-interrupting) by preceding it with a backslash (e.g., \===
).