There are two ways in which Parsoid trips on templates that cause a wikitext construct to be split across top-level-content and templates.
* In one form, the first part of the construct swallows not just the other part of the construct, but also following tokens / content into its attributes (T48811 is an example of this)
* In another form, the construct is split between two adjacent tokens, and we need to bring that content across tokens. (T69857, T69850, T52603, T46498)
The longer term fix for both these issues is to start scoping the output of templates to return DOM-representable strings and split some of these monolithic templates into multiple templates, one that generate just the attribute, and another that return just additional content. This also improves WYSIWYG editability of some of these tables.
In any case, till such time, we need to continue supporting these forms. Both forms seem to affect tables. The first form is seen when a template is used in the table-attribute (and possibly table-row-attribute) position. The second form is seen when a template is used in table-cell-attribute position. The reason why we these two different manifestations of the same problem is because of the peculiarities of how the table-opening-tag and table-cell-tags are tokenized and what the tokenizer can assume.
The second form is addressed by the code in dom.t.TableFixups.js where the DOM is examined to bring together the split pieces. However, so far, it only supports templates that generates attributes of a table-cell and a single following table cell. But, we now need to generalize this support to support multiple table-cells being generated by these templates to cover the last of the big unsupported scenarios.
Example wikitext for it is:
```
{|
|{{convert| 400|m|ft|disp=table|sortable=on}}
|}
```
This affects enwiki:List_of_largest_container_ships (among possible other pages). Generalizing the code in dom.t.TableFixups.js should probably take care of this.