My guess is that once html is detected, the following line is both sucked into the processor and subsequently not parsed for markdown. You can test this by putting some text on the line after the div and at the beginning of the next line:
<div>divved text</div> end of div
beginning of markdown [a link]( `/admin/email/templates`.) **italic**
divved text
end of div
beginning of markdown [a link]( `/admin/email/templates`.) **italic**
The key rule is HTML block type 6. The CommonMark spec explicitly lists div(along with p, blockquote, table, h1–h6, ul, ol, li, hr, etc.) as a block-level tag. When the parser encounters a line starting with one of these tags, it opens an HTML block with this end condition:
End condition: line is followed by a blank line.
Your other examples are inline elements, and behave differently.
In making my report simple, I forgot to mention that the issue came up when a user inserted the <div data-theme-toc="true"> </div> code to insert a table of contents. It seems like it’s an issue for the developer of that feature if anyone.
It’s the precise positioning of the <div data-theme-toc="true"> </div>. In this case it was the first thing in the post and text started on the next line. We wouldn’t have even noticed if that first line didn’t contain markdown. Not sure if that makes sense.
