Need to generalize when domains are specialized from structures

This is where the syntax for @domains tokens really went off the rails, in DITA 1.2 and 1.3. There is a theoretical value here, for complex specialization modules that rely on unrelated modules.

However: although such modules exist, they are not common, unlikely to be generalized, and the token syntax is so complex that I doubt anybody will ever figure out how to make use of it.

As a highly improbable example, imagine I've created a domain with the specialized section <goofyStuffToDo>. That section nests <steps>, which is pulled from the Task structural specialization. So far so good - complicated and a bit of an edge case, but legal and useful.

Now imagine that for some reason this domain is made obsolete, and I want to turn <goofyStuffToDo> back into <section>. If I do that on its own, the <steps> element ends up invalid - because it's not allowed inside a normal section. This means that if I ever generalize my domain, I also need to generalize any task related elements inside.

Wait, what now?

Generalization is already an edge case; chances of needing it here => truly the bleeding edge.

Like, really way out on the edge.

If I ever decide to generalize this sort of document, I'm willing to bet I'll just be converting everything I find back to a basic topic, in which case the token is irrelevant. Remember - the token is only useful if I want to generalize this module (plus any dependent modules) to something other than topic.

This is so unlikely, I can't see any case where it is worth supporting. Even if I thought I was ever going to encounter this, the domain token syntax is so complicated that I doubt I could implement it. With syntax so complex that the implementation becomes near-impossible, what was the point of the syntax?