Traditionally Translate, similarly to the good old legacy parser, works with chunks of text. It knows nothing about the DOM, and very little about wikitext, giving much room for translation administrators to split up pages to translation units however they like (and shoot themselves on foot by, for example, putting the first half of a huge wikitable in one translation unit and the other half in the next one – no <div> wrapping will be able to handle this). Luckily, one of the few things it knows about wikitext (since T62544) is how headings look like (for which it partly reimplements the core parser). However, if your advice is followed and the markup is inside the <h2>, there are two possibilities:

• Use a <span>. This looks bad: now only the text itself is highlighted, not the whole heading.
• Use a <div>. This probably looks the same as before (tested on Vector 2010, Vector 2022 and Timeless), but means that the <div> is a child element of a <span> generated by the core parser, i.e. a block element is within an inline element.

Maybe the class should be put on the heading element rather than inside it, resulting in <h2 class="mw-translate-fuzzy">. Which is probably difficult and error-prone to do entirely in the extension, calling out to Parsoid would be safer.

Also, all this assumes that the wikitext looks how it should. Of course, it won’t. There are many ways for it not to look like how it should (e.g. by involving templates), but a pretty common (although not recommended) markup is the following:

<translate>
<!--T:1-->
== Lorem ipusm dolor sit amet ==
Nobis libero iure eveniet ad sunt qui minima et. Excepturi consequatur cupiditate non dolorum esse. Quaerat saepe consequatur assumenda deleniti exercitationem voluptatem placeat. Non quaerat aut qui quod. Ducimus quia est et ea ut dolore corrupti. Quae ipsam eveniet non. Sed autem et placeat. Qui numquam optio quasi assumenda error explicabo sint et. Laborum laboriosam sint distinctio id et. Ipsam vero beatae eum enim aut qui. In dolores sit sint dignissimos commodi quis optio. Itaque et voluptas explicabo qui.

<!--T:2-->
Ad et consequatur facilis veritatis et. Maxime maiores esse aut voluptas ut doloremque. Rerum odio harum et autem asperiores. Id doloremque sint et ut laborum est et. Sit aliquam error excepturi facilis similique. Neque perspiciatis similique rerum dolorem. Explicabo et omnis cumque consectetur quisquam animi nihil ut.
</translate>

i.e. the heading and the first paragraph build a common translation unit. In this case, since the <div> wraps a single translation unit, we can’t do anything but put that opening <div> before the heading.

Speaking of T62544, another thing I noticed in your HTML excerpt is that the <span>s introduced by that task are parts of the preceding <section>s. This is probably why opening https://test.m.wikipedia.org/wiki/Translate_headings/pl#C uncollapses B pl instead of C pl.

This almost feels like we need a wikitext extension to produce more complicated headers. Perhaps a parser function where we can specify additional classes? Although with some hacky code we could also produce <h2 class="mw-translate-fuzzy">foo</h2> from Translate, I am not sure if it will result in a good normal header with the parser/parsoid.

Regarding the poor mark-up example from @Tacsipacsi, I think we could make our translation section parser more aggressive and force header and following paragraph to be separate units. That would remove some flexibility from users, but it might be for the better.

I also thought about a {{#HEADING-ANCHOR|}} parser function for T62544 and followups, but that would require a new core hook to edit the heading.
We may want to mix both parser functions with something like {{#HEADING-EDIT|anchor=|class=}}.