There are a number of instances where Parsoid needs to represent a DOM range. The obvious cases that Parsoid has worked with so far have been output of templates and extensions. In the cases where the DOM range for a template and an extension overlap, there is a clear nesting (ex: extension output contains templates OR template output contains some extension) and in those cases, Parsoid has simply resorted to privileging the outer nest and suppressing information about the inner nested component.

Given this stragegy, Parsoid has used a typeof on the first element of the DOM range to indicate the type of DOM range it is (mw:Transclusion, mw:Extension/*) and an unique about id that is assigned to all the elements of the DOM range.

Going forward, we might have other use cases for DOM ranges (ex: annotations -- see T261181) and we might also want to have all DOM ranges be extractable rather than arbitrarily pick the outermost nesting.

So, we need a different spec that lets a DOM node be part of multiple ranges and of different types. So, we need a different representation scheme for encoding these ranges that is efficient space-wise, intuitive, and also lets clients easily extract the various DOM ranges and manipulate them in an error-free manner without a lot of complexity. So, given these requirements, the typeof-aboutid mechanism we have been using so far will not work.

We may also need to get feedback from existing Parsoid clients as part of developing this new spec.