See bug 55524. Transclusions can currently affect arbitrary parts of the page by producing unbalanced HTML. This makes both WYSIWYG editing and efficient updates difficult. We would thus like to move towards properly nested templates as much as possible. For existing multi-transclusion content we would like to enforce nesting as a unit using a <domparse> extension-like tag wrapping such a content block.
The other use case is support for non-wikitext content. Daniel Kinzler is working on this patch. The issue here is that HTML transclusions can be nested deep inside of normal wikitext transclusions. The idea is for the PHP preprocessor to not expand those when they are nested, and instead wrap them into a <domparse></domparse> tag. Consumers like Parsoid will then pick up the <domparse> tag & expand it with a separate request to the PHP API.
The PHP action=expandtemplates end point will add a top-level content type to each expansion result (as a property in JSON & an attribute in XML). Consumers will use this to determine how to further process the returned content. The normal case would be to return something like 'text/x-wiki;expanded', which means that it's wikitext which might or might not contain <domparse> tags. The expansion of a single HTML-only transclusion will be marked as 'text/html', so that consumers can process it as fully processed HTML.
Re-expansion of transclusions in VEEdit
Re-expansion of transclusions when editing in VisualEditor sometimes depends on a DOM context. An example would be the re-expansion of a template producing a complete table row. The HTML5 DOM parsing algorithm strips
<tr> any other table elements outside of tables, so VE would need to pass in some kind of DOM context wrapper to let the table elements survive, and then strip that wrapper again from the result.
<domparse> VE will have a natural re-expansion boundary for typical multi-template tables or lists, and won't have to add logic to insert and remove custom wrappers.