The core parser emits links to edit every section; right now we emit both 'edit' and 'edit source' links, but it (AIUI) depends on some user and wiki configuration as to how many edit links we emit, whether we emit links to visual editor, etc. But in any case, Parsoid needs to be compatible & emit these before it can replace the legacy parser for read views.

This would (likely) be a post-processing pass, as the exact links emitted is user-dependent. It would also ensure we don't clutter/invalidate parser tests every time we decide to tweak how the section edit links look or what editor they link to, like the legacy parser does.

A simple test case: https://en.wikipedia.org/wiki/User:Cscott/Parsoid_section_test

Note that transcluded sections also have direct links to edit the page on the transcluded section. On the example page these look something like:

https://en.wikipedia.org/w/index.php?title=User:Cscott/SectionTemplate&veaction=edit&section=T-1

Note that we don't currently make any guaranteees about content inside a transclusion. Properly emitting the above links would probably require us *not* to strip some Parsoid info from the transclusion and come closer to guaranteeing that the contents of a transclusion are a valid Parsoid document with its own data-mw and data-parsoid that can be interpreted to reconstruct the template tree. See T269629: Generalize rules about rendering-transparent content before sections, T260169: Parsoid API to "expand page X with parameter Y and Z", and T259824: DiscussionTools's reply tool doesn't work when the comments are transcluded from another page using a template (not directly) (where DiscussionTools has to chase down recursive transclusions to find the "true" page holding a given discussion topic/reply/etc).

See also: T270199: Table of contents in Parsoid output.