The core of the problem, is that GenericSetup profiles are additive. Sometimes products can't be upgraded by simply applying profiles and the whole chain of profiles needs to be applied in a certain order.
For example, say we have a lot of independent site policies (only one of them applied to the plone instance): S1, S2, ...., SN. And a couple of products, say A and B. For example, all those S1-SN, A, and B have metadata dependencies go like this: Sn -> A -> B
Suppose they deal with registry.xml and override something along the way. (The same can be the case from typeinfo and some other profile steps). If something changes in the product A, which may or may not be overriden in S1, we can't just perform an upgrade step for A, because when we press the button on the S1 site, its own policy overrides will be lost. However, it's a big deal to write upgrade steps for all of S1-SN just because a change in the A.
Is there any smart way to do upgrades at least for the case depicted above, when the whole problem would be solved by applying registry update in certain order, namely: B, A, Sn. (even then, there could be some hard cases)?
Since the package A has no idea of S1 (or S2 or whatever site policy happens to be), one solution is to make some "superpackage" which could have explicit knowledge about those chains of upgrades. But are there other solutions apart from always putting the resulting profile to the policy?
(For simplicity, lets forget that some changes could be done through the web)
Decided to go with custom solution, with helper functions to make common upgrade task easier. Doesn't solve all the problems, but helps deployment.