This is the 'nested data-mw' issue, where the outer template includes an inner template, but the data-mw for the inner template (which says which template *actually* got included). This is a case of T214241: data-mw info is clobbered by template annotations...

...but there's a second issue here, which is that generally speaking we strip parsoid markup in the inner templates, in order to avoid bloating the payload. So stripping the second level of indirection is "by design".

Here's a short parser test which demonstrates the issue, more or less:

!! article
Template:Include
!! text
This is the thing included:

{{ {{{1}}} }}
!! endarticle

!! test
Including an include
!! wikitext
{{Include|:Main Page}}
!! html/parsoid
<p typeof="mw:Transclusion" data-mw='{"parts":[{"template":{"target":{"wt":"Include","href":"./Template:Include"},"params":{"1":{"wt":":Main Page"}},"i":0}}]}'>This is the thing included:</p>
<span> </span>
<p>blah blah</p>
!! end

Note that the Parsoid markup has lost all information about the fact that it is actually [[Main Page]] which is being included.

DiscussionTools currently does follow the chain of transclusions (up to ten deep) so if {{Foo}} is included it asks RESTBase for the parsoid HTML for Foo and then proceeds to work on that. But if the transclusion is {{Foo|Bar}} there's currently no way to ask RESTBase to render "Foo" with parameter "Bar", so there's no way to properly recurse.

Something like the following is present in the nested transclude:

<p about="#mwt1" typeof="mw:Transclusion" data-mw='{"parts":[{"template":{"target":{"wt":"Discussion/{{{1}}}","href":"./Template:Discussion"},"i":0}}]}' id="mwAg">

So while it's pretty ugly, I think I'm suggesting that the short term strategy is to regexp-match parts[1].template.target.wt against {{{\d}}} and to substitute in the parameter (from the parts[1].template.params of the parent) in that case when DiscussionTools manually does the recursion.

The "proper" solution will be to add a params parameter to the RESTBase/ParserCache/Parsoid API to ask specifically for an expansion of [[Title]] with specific parameters X and Y etc. (Are X and Y specified in wikitext, HTML, ?) This would then get cached and bring us one step closer to our incremental parsing roadmap. But that's going to be a long term project to hammer out that API, especially given the state of flux of RESTBase/ParserCache, so the ugly approach above is probably best for now.

@Whatamidoing-WMF shared that her team hasn't found any templates they encounter regularly, asked village pump tech today and should have more information tomorrow. There has been a lot of innovation from that community.

In T259824#6406928, @JTannerWMF wrote:

@Whatamidoing-WMF shared that her team hasn't found any templates they encounter regularly, asked village pump tech today and should have more information tomorrow. There has been a lot of innovation from that community.

Sherry and I talked about this today. We have not yet received responses about this convention at en.wiki's Village Pump Technical. [i]

Next, we'll reach out to ko.wiki to learn more about the convention.

From the Editing Team's perspective, we're going to wait on addressing this issue in software until we have evidence of the following:

• The 알찬 글 토론 template is used widely at ko.wiki
• The functionality the 알찬 글 토론 template achieves cannot be achieved in a way that is compatible with the Reply Tool.

Next steps

• @Whatamidoing-WMF is going to ask volunteers at ko.wiki how widely this convention is used at ko.wiki and how it came to be used there.

i. https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Looking_for_page_transclusion_templates

AFAICT, from the end-user's perspective, this error, and the workaround, are the same as any page that uses open tags to create a colored background or other fancy formatting, e.g., https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_COVID-19

Also, even if this technical problem were fixed, I think you still couldn't use the Reply tool, because you can't edit sections with {{collapse top}} and {{collapse bottom}} around them anyway.

That's a slightly different case, this one should be somewhat easier to solve, since the comments are written on a separate page without wrapper templates like that.

Similar situation where a discussion page is transcluded using a template: https://pt.wikipedia.org/wiki/Discussão:Feudalismo

Similar problem affects the comments sections of English Wikipedia's The Signpost, such as this one: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2021-06-27/Forum#comments (in this case the discussion is transcluded from the talk page: https://en.wikipedia.org/wiki/Wikipedia_talk:Wikipedia_Signpost/2021-06-27/Forum).

Reported again: https://www.mediawiki.org/wiki/Topic:Wjwftp9u53y8ot0f

Another one: https://www.mediawiki.org/wiki/Topic:Wnvxxmloqpk79fvq

New case. As it is a painful, recurring problem, I thin we should discuss it one more time.

If you have

<p about="#mwt1" typeof="mw:Transclusion" data-mw='{"parts":[{"template":{"target":{"wt":"Discussion","href":"./Template:Discussion"},"params":{"1":{"wt":"Test"}},"i":0}}]}' id="mwAg">Hello world</p>

couldn’t you pre-save transform {{subst:Discussion|1=Test}} and then look for transclusions in the result? Or send {{Discussion|1=Test}} through what Special:ExpandTemplates uses if it’s Parsoid-compatible yet?