Cases like T187958 and T189474 keep cropping up as we approach the long tail of parser convergence.
These quirks seem more like by-products of the current parsing behaviour rather than explicit goals in the language and, where possible, we should try to eliminate them rather than seeking to support the additional complexity.
But, if / where subsets are absolutely required, they should be handled systematically and uniformly everywhere (extensions, templates, messages, UI, etc.).
My intuition is that the way we will eventually handle subsets will fall out of the way we add strong types to "trees" and "holes". That is, if a particular extension wants something that fits an "inline"-shaped hole, but is given something which is a "block", there will be a well-defined conversion mechanism (stripping the block tags, presumably). Similarly, if the hole is in a "link caption" context but we're given a "link", we'll strip the link to avoid a link-in-link error.
That is, there won't be wikitext subsets, per-se, but there will be "allowed"/"disallowed" constructs based on composition rules.
Yes, makes sense to me. https://www.mediawiki.org/wiki/Parsing/Notes/HTML5#Composition_Spec_notes has some strawman notes.
Removing task assignee due to inactivity, as this open task has been assigned to the same person for more than two years (see the emails sent to the task assignee on Oct27 and Nov23). Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome.
(See https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator.)