cscott is working on this project Parsoid, and I hope he could help. At least, he should be a subscriber.

Adding Content-Tranform-Team to the set of tags (or, indeed, Parsoid and/or Parsoid-Read-Views) is sufficient to ensure our team sees it and triages it to someone who can work on it.

For context during triage: https://www.mediawiki.org/wiki/Parsing/Notes/Section_Wrapping is how parsoid section numbering should work. There are corner cases where parsoid will disagree with the legacy parser wrt section boundaries, but parsoid *should* use section-id=-1 for these cases.

Could be related to T222419: Incorrect section numbering after unclosed subst or T215628: Make Parsoid and PHP edit-section numbering consistent when <noinclude> and <includeonly> are in use.

I've looked into that yesterday (and put my notes in T222419#10058673); I am not *convinced* that it requires the wikitext to be invalid for it to trigger. The PEG parser might backtrack on valid-wikitext-that's-just-ambiguous-enough, without the wikitext itself being entirely at fault. I think.

Just recording for debugging purposes since this is not reproducible on the current version of the page, if you 'view source' on https://en.wikivoyage.org/w/index.php?title=Emeryville&oldid=4921380 , you can see the bad section ids on the section wrapper tags.

This snippet below is sufficient to reproduce the id-assignment issue:

=S1=
[[Foo|Bar],]

=S2=
x

See Parsoid's output below -- S2 gets id 3 instead of 2.

$ php bin/parse.php --wrapSections < /tmp/wt
<section data-mw-section-id="0" data-parsoid="{}"></section><section data-mw-section-id="1" data-parsoid="{}"><h1 id="S1" data-parsoid='{"dsr":[0,4,1,1]}'>S1</h1>
<p data-parsoid='{"dsr":[5,17,0,0]}'>[[Foo|Bar],]</p>

</section><section data-mw-section-id="3" data-parsoid="{}"><h1 id="S2" data-parsoid='{"dsr":[19,23,1,1]}'>S2</h1>
<p data-parsoid='{"dsr":[24,25,0,0]}'>x</p>
</section>