This seems like a good behavior to me… What do you think should happen?

If such markup generated an editable section, but identical markup with a template that returns something didn't, then by editing the template, you could change the number of sections in each page that transclude it, which would have unpleasant consequences (e.g. any edits in-progress would overwrite the wrong section when saved).

I would expect the header not to be a header like it does if it's followed by a template that returns something (or for the header to be parsed in both cases). It's also worth noting that parsoid doesn't parse the heading in this case.

Hmm, that is actually what happens in Parsoid: https://en.wikipedia.org/api/rest_v1/page/html/User%3ABrandonXLF%2FT254119

I'm going to comment here only on the Parsoid vs. core parser difference.

This is a known issue and there is probably a whole class of wikitext snippets where such differences manifest. Core parser output is an outcome (vs something deliberately designed to be that way) of how it processes wikitext and Parsoid's output is likewise a result of how Parsoid does things. In the case of Parsoid, some of this is deliberately designed to ensure that we can gradually nudge behavior to decouple parsing of pages from parsing of templates, i.e. whether something is a heading or a list should not largely depend on intervening transclusions.

While adopting that decoupled parsing strategy, we are also taking care not to break things unnecessarily. So, if something is a common use case, we'll ensure they work. So, unless it is a very common use case, we are willing to break these edge cases. I think it is okay to solidify the behavior that transclusions after heading wikitext will disable the heading parse (no matter what the transclusion returns). So, both those headings don't parse as headings in the Parsoid world.

To add to that, I also note that if core parser parsed that wikitext like Parsoid did, the bug would not be a bug ... i.e. both those are not sections and hence not editable vs this mishmash where one is maybe a section that is not template-generated but is still not editable.

Any reason not to decline this?

Consistently not rendering == as a heading if the line has trailing other syntax makes sense indeed. The legacy parser has inconsistent behaviour which Parsoid would fix.

Is there a general tracking task for switching to Parsoid? Or do we just decline these rather than stalled/depends-on?

In T254119#6186424, @Krinkle wrote:

Consistently not rendering == as a heading if the line has trailing other syntax makes sense indeed. The legacy parser has inconsistent behaviour which Parsoid would fix.

Note that Parsoid allows trailing comments (since this is probably not so uncommon and desirable and doesn't break the principle of decoupled parsing).

Is there a general tracking task for switching to Parsoid? Or do we just decline these rather than stalled/depends-on?

I recommend declining because there are likely many such edge-case scenarios that aren't worth clulttering the dependency tree with. Substantial divergences (that are nevertheless acceptabe, like for example extension APi changes) are probably worth tracking and adding dependencies on.

Interesting, so, in a way, Parsoid allows writing whole sections inside a title. (not that I'm complaining, just a very unrealistic case I noted).

== {{text|

title 1

==title2==

section 2 content

}}==<!---->