Test case:
https://en.wikipedia.org/wiki/German-suited_playing_cards?useparsoid=1
where it manifests as floating section links. The wikitext looks like:

{{anchor|Ruimpf cards|Ruimpfkaten|Rümpffkarte|Rümpfkarte|Rumpfkarte|Rümpfspiel|Ruimpf|Ruimpfspiel}}
===== Ruimpf cards =====

which is generating:

<span id="Ruimpf_cards"></span> ....
<h2 id="Ruimpf_cards_2">

and we're wrapping the <span> not the <h2>.

Note that the legacy parser generates the follow HTML, which is *technically* invalid because of the duplicate IDs:

<span id="Ruimpf_cards"></span> ....
<h2 id="Ruimpf_cards">...

Parsoid is doing the right thing by deduplicating IDs and giving the deduplicated ID Ruimpf_cards_2 to the <h2>, but apparently we're creating the TOCData before the deduplication occurs (or not updating the TOCData when the heading is deduplicated) and so our TOCData ends up incorrect.

Another useful test case is:

==Foo==
==Foo==

Even the legacy parser deduplicates this case correctly (the second heading gets id Foo_2). I'm not sure what TOCData Parsoid generates for this case, but I strongly suspect we have the same bug -- ie, correctly deduplicate the HTML but have anchor=Foo for both SectionMetadata objects in our TOCData.

We could also consider emitting lint errors when we deduplicate IDs.