The current text seems to assume that DOM sections would be used directly against wikitext section edit APIs. Is this actually needed or desired?
Topic on Talk:Parsing/Notes/Section Wrapping
Yes, it does. Why should we introduce different notions of sections, one for reading and one for editing? Do note that for the most common use case where we don't have malformed sections in wikitext, there are no conflicts between the two notions.
In edge cases, current edit sections don't necessarily align with DOM structures. Unless you are willing to break up DOM structures (which has many issues), there will be incompatibilities with the old-style section edit API.
Rather than defining sections around edge case bugs in the current section edit functionality, I think it makes a lot more sense to focus on product needs and user expectations. We can update APIs to respect DOM sections, rather than limiting DOM sections by old API issues.
Understood.
The plan (proposal 1) is indeed to add sections around DOM structures in those cases, but to then disable editability for those with the current save API. When the API changes or when we decide to enforce well-formedness of sections / templates / etc, editability can be enabled.
I had temporarily proposed one such different save API based on source offsets, but then quickly realized that it was a broken idea and removed it.
So, we are on the same page here as far as I can tell. The primary difference from what you have is to add a mapping with the MediaWiki section numbering that ensures that section tags can be used by editing clients and have the guarantee that they won't corrupt the page if they use the section edit API.
We already offer editing of DOM sections in the REST API. The main issue right now is that those "sections" are too fine-grained (all children of body), which is one of the issues the <section> wrapping discussed here should resolve.