Thanks for the report. I think the issue is slightly different than what you described. What I am seeing here is:

• The DiscussionTools diffs (e.g. https://en.wikipedia.org/w/index.php?title=User_talk:Ahecht/sandbox&diff=1026132646&oldid=1026132531&diffmode=source) are not modifying anything else on the page, and are not inserting unnecessary nowikis
• But despite that, the edit breaks the page, here's the comparison:
  • Before: https://en.wikipedia.org/w/index.php?title=User_talk:Ahecht/sandbox&oldid=1026132531
    
  • After: https://en.wikipedia.org/w/index.php?title=User_talk:Ahecht/sandbox&oldid=1026132646
    

The problem actually occurs because the page has an unclosed <nowiki> in an earlier comment. It's easy to find in the wikitext editor if you enable syntax highlighting:

To avoid the issue, I think DiscussionTools actually should modify that unclosed tag! (Technically, that would happen in Parsoid.) This is what happens in other cases – e.g. if there's an unclosed {{ somewhere on the page, it gets wrapped in nowiki, so that adding }} in another comment doesn't wrap all of the comments inbetween in a template.

Good catch. I was wondering why the <nowiki> wasn't being displayed as a change. I agree that, if the previous tag was being ignored by the parser because it was unclosed, adding a reply should try to keep that status-quo.

Briefly, the proposed solution from the Parsing side is that we should add a lint for "unclosed nowiki" (if there isn't already one, there may well be, "unclosed tag" is probably close enough) and then have DiscussionTools check the lints for the given page before saving (or starting?) an edit and warn the user if there are "problematic" lints for the page. It doesn't (shouldn't) be too fancy: no need to detect whether the edit-in-process contains a <nowiki> for instance -- there are too many corner cases here to spawn endless ratholes to waste time in. It should just be a big hammer where if there are lints in a given set of categories present the user will be warned, and we can add new lints to that category as we find new cases of this sort.

So in this sense the editor would be warned there was an unclosed tag (or specially an unclosed <nowiki>) on the page at some point during their comment, which would make it clear what's happened when their edit appears broken. Longer-term, de-linting work by wiki gnomes will fix the fundamental issue, and things like "balanced sections" will help mitigate their effect.

That would work for us, since we already check the lints for fostered content (for T246481).