Potential approach
In discussing this with @Esanders, he shared one approach we could take to adding the support this task is asking for...

Add logic to the Reply tool that removes indentation syntax (e.g. : and *) from content that is contained within an extension (e.g. <math></math>).

• Concerns:
  • Such an approach would start us down the path of parsing comment contents which means...
    • A. We would have more to maintain (in this case, a list of extensions) and
    • B. We could be duplicating work the parser (legacy and Parsoid) are already doing at "save"
• Considerations:
  • Any code we write to add this support now, would become obsolete once new syntax for multi-line comments is implemented (T246960).

Will discuss this next Tuesday, hopefully get some input from @cscott

A note on timing after a quick chat with @Esanders:

• If we work on this, that work should not happen until we are confident T234403, particularly switching between visual and source, is working well.

I think that https://hu.wikipedia.org/w/index.php?title=Szerkesztővita:Pasztilla&diff=22578512&oldid=22578493 is the same category of problems, but it involves MediaWiki core's <gallery> tag. (In this case, the automatically added signature was not correctly indented after the gallery tag).

My note on this is that extension parsing is in theory not one of the "evil" parts of wikitext parsing. After the open tag is seen, the close tag is found using a fairly braindead regexp, more-or-less deliberately. ("You can include any content in extension content except </closetag....".) The only tricky part might be attribute parsing inside the open tag, but IIRC the sanitizer does this with a regexp so you should be able to do that as well. So, yes, it's a slippery slope, but at least the slope isn't *too* steep in this general area.

Just to not get forgotten from T253482: this should apply to template parameters as well.

In T251633#6129747, @cscott wrote:

My note on this is that extension parsing is in theory not one of the "evil" parts of wikitext parsing. After the open tag is seen, the close tag is found using a fairly braindead regexp, more-or-less deliberately. ("You can include any content in extension content except </closetag....".) The only tricky part might be attribute parsing inside the open tag, but IIRC the sanitizer does this with a regexp so you should be able to do that as well. So, yes, it's a slippery slope, but at least the slope isn't *too* steep in this general area.

Wikitext can contain normal HTML tags, and those might come without a closing pair, which makes tag parsing more annoying than it would otherwise be (and also makes it impossible to use Javascript's built-in XML parsing capabilities). I suppose you can fetch the list of registered extension tags and only apply the logic to those.

You can do it for <pre> as well, but it’ll remain broken anyway unless its behavior is changed in core.

<pre> is treated as an extension tag, by parsoid at least.

Would note that this is something Convenient-Discussions supports from time immemorial. Quick example from 2020: https://ru.wikipedia.org/?diff=108630321

So if some people have a lot of issues with using code in DiscussionTools, that can be a temporary fix (and a switch to a superior comment system).

Handling the ever-increasing number of duplicate bug reports takes an ever-increasing amount developer time. Wouldn’t it be less time-consuming in the long run to spend time on fixing this now, and then forget about it?

@Tacsipacsi: https://en.wikipedia.org/wiki/User:Du%C5%A1an_Krehe%C4%BE/Signpost_draft:My_idea_about_wikipage_parser

@Tacsipacsi: This is one more indenting error using DiscussionTools, see this diff https://en.wikipedia.org/w/index.php?title=Wikipedia:WikiProject_Resource_Exchange/Resource_Request&diff=prev&oldid=1185375661

*: insted of *:::

First, why are you directing this at me? I’m neither a decision-maker nor a developer who has ever committed anything in DiscussionTools.

Second, it has nothing to do with this task: this task is about multi-line extension tags and templates, not about random indentation issues.

Third, it’s by design: since you wrote your previous comment in the middle of the initial comment by A Cynical Idealist, everything in their comment that is now before yours (i.e. the first citation) became part of your comment, and thus your comment is indented by one bullet point and zero colons, so the reply naturally comes indented by one bullet point and one colon. Even I as a human had hard time understanding who wrote what, so don’t expect the software to know what you mean.