While investigating current templated sibling node use cases in the Parsoid DOM spec, I noticed that several template-affected structures aren't consistently marked as such in Parsoid output.
List not marked as template-affected despite templated list items
Input:
* foo {{echo|* bar}} * baz
Result: Only the 'bar' list item is marked as template-affected.
Expected result: The list is marked as template-affected. If the embedded template returned just 'bar', the entire list would break up, despite the list not being template-affected. The rendering as a list thus depends on the wikitext returned by the nested template, which isn't predictable in the general case. The list element is the closest DOM scope, so should be marked as template-affected, as it might be broken up into two lists depending on the return value of the template.
Table not marked as template-affected despite templated table cell / arbitrary element
Input:
{| | foo {{echo| {{!}} bar}} |}
Result: Only a single table cell is marked as template-affected.
Expected result: Since the table is the closest containment structure / DOM scope that can be reasonably expected to contain any sensible expansion of embedded templates, it should be marked as template-affected.
This is indeed what happens when the template returns slightly different wikitext, illustrating the inconsistency in behavior:
{| | foo {{echo| {{!}}- {{!}} bar}} |}
Both cases suggest a need for a more consistent definition of DOM constraints and -scopes, as discussed in the Parsoid/DOM_notes page on mediawiki.org and T114444: [RFC] Introduce notion of DOM scopes in wikitext.