(In reply to comment #2)
> {|
> ! Foo !! Bar
> |-
> === Section 1 ===
> |-
> | Foo || bar
> === Section 2 ===
> |-
> | Foo || bar
> |}
> 
> Coming up with a solution to this is would be a significant piece of
> engineering effort for marginal utility.

The section editing feature in the old parser works by excluding all sections headings where the heading is not a child of the document root. The previous section thus runs on past the excluded heading. This means that a section can always be represented as a set of adjacent DOM subtrees. It seems to me that the same solution could be implemented in VE. 

The definition of "children of the document root" would change somewhat, since it is a different kind of DOM, so the number of excluded sections would be larger, but it would still be a better solution than what we have now.

> * The reasons we brought in section-editing originally were two-fold - to
> skip
> past confusing wikitext in other areas to find the item you actually wanted
> to
> edit (not an issue in the context of VisualEditor), and to avoid edit
> conflicts
> using the page-based diffs at the time (not an issue for ~ 7 years since Tim
> re-wrote the diff tool).

Section editing has never had any special case to help with edit conflicts -- it was always dealt with using the generic three-way merge feature, which, for the record, I did not write.

I think the main two reasons for implementing section editing were bandwidth and avoiding the need to scroll. Erik's original post on the subject suggests as much:

http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/3433

Note that it was implemented at a time when 56k modems were still common -- I had one at the time, and I was certainly glad of the performance improvement.

> * Editing by section blocks users from editing other areas at the same time
> that the notice flaws in after they've entered editing, for very limited
> added-value.

For large articles, I think the added value would be very large indeed. People don't want to wait tens of seconds to make a small correction, and it's likely that VE performance causes many edits to be abandoned.

Perhaps there are other solutions for the performance issue, but it seems to me that this is a fairly obvious approach, especially for bandwidth reduction.

Yes, the existing feature prevents users from editing other sections on the page, which sucks. That could presumably be addressed in VE: a separate content-editable region could be created by each section edit click, to be saved in bulk.