Thank you for mentioning those specific examples here. I had no idea that this was part of the problem you were talking about. (At this point, this isn't really directly related to the original subject of this thread, so apologies if I've ended up sidetracking this discussion.)
Considering that the earlier Phabricator task was declined and the later one was merged into it, the clearest options to me would be to either increase (or remove) the limit, or do nothing. Changing the behaviour now would have the side effect of potentially breaking wikitext that has been written since the RemexHtml transition, would take RemexHtml out of compliance with the HTML5 standard, and would require more effort on the part of the developers than doing nothing. I think I would agree that the algorithm (as specified) doesn't really seem suited to the specific task of fixing wikitext misnesting, mainly because of the unusually low numerical limits, but there are still good reasons to keep Remex as it is. (I also don't know how easy it would be to get a +2 on such a change, since Remex was most likely stabilized a while ago.)
If there isn't anything to be done, there isn't much of a point in discussing this particular part of the issue here. If you think there's a case for reopening phab:T199057, then... well, this isn't really the place either.
On Wikiwiki, everything between a tag pair is affected by that pair.
Obviously this is supposed to be a comparison between parser.php+Tidy and parser.php+Remex, so I think it would be best not to oversimplify and claim that Tidy was able to do this perfectly.
For Tidy (as well as Remex, in most of these cases), the claim that misnested markup will always work isn't true for many combinations of misnested tag pairs (notably those involving pre, nowiki, ref, noinclude, includeonly, onlyinclude, and some extension tags), isn't true for many misnested combinations involving wikimarkup (particularly combinations of wikimarkup and XML), and generally isn't true for misnested combinations involving templates or magic words. (Tidy also breaks certain combinations of XML with wikimarkup even with correct nesting.) It follows: this behaviour was already somewhat inconsistent to begin with, so is it necessary to keep the behaviour precisely as inconsistent as it used to be?
(Incidentally, I couldn't find any wikis with Tidy still enabled, so I couldn't actually test these. I'm fairly confident in this being accurate, but it would be nice if these things could be tested without having to bother with installing MediaWiki locally.)
It was broken in pursuit of a purely internal agenda.
My understanding of the situation is that HTML4 Tidy had to be replaced anyway because it was no longer maintained, and this particular issue came up because Remex (which was written specifically as a Tidy replacement) exactly follows the parsing algorithm in the HTML5 specification, which can be somewhat problematic for the reasons you've mentioned.
It's definitely clear that there is a strong internal developmental agenda – that is, aiming at replacing the current wikitext parser with Parsoid – but there seem to be clear benefits from transitioning to Parsoid, although I think it would be fair to state that most experienced contributors wouldn't directly benefit much from the change. I don't think the existence of an agenda in itself is particularly problematic, although I haven't really followed discussions on Parsoid closely.
The point of a wiki, the point of wikitext, is to be understandable and usable by average people who don't want to learn strange and obscure HTML rules.
I don't think it has really succeeded in doing that, even if it's better than HTML. Even aside from the difficulty of learning all of the markup, wikitext still has its own idiosyncrasies, such as the impossibility of nesting <ref>
tags without using a parser function. Obviously, the development of VE is primarily a consequence of the perception that wikitext was not sufficiently accessible.
As for what Parsoid actually means for this project, I think the situation may be clearer once the team posts answers to the questions I asked in my second-last comment.
If it were up to me, I might not go as far as to automatically mess with the input to the source editor; extending the linter or adding tracking categories would probably be better for handling markup errors (and might encourage users to fix the errors in the first place). I think following the 2017WTE behaviour would make a lot more sense than following the SD behaviour, but at this early stage both could still be possible.
It's also been suggested to "armour" comments so that unbalanced markup doesn't spill into the rest of the page, which could be possible with a magic word that forces each comment to be parsed separately.