A reasonably new change is this:
What exactly is the point of this ? I've read the docs from top to bottom and it is completely unclear.
What does this add ?
If I have a working configured dev GW for example, with an installed OTK, all configured for dev, integrated with the customers systems - all customised, etc as required what I WANT to be able to do is treat this absolutely no differently from any other policies/config I am migrating to a higher environment (e.g. TEST).
Now I know this works, as I've done exactly that before, migrating the OTK, selected APIs, etc that I want to be moved to TEST and GMU does what I expect it to do.
I can then template it, make whatever changes I need in there, or occasionally after migration (JDBC connection, etc).
The result works fine.
I can't see what you are trying to achieve with this separate contrived model of migration ? Is it because some solution kits, like the MAG include custom assertions and would otherwise not work through GMU ?
Even i that IS the case, I fail to see what problem you are trying to solve here ?
I realise you want to constrain changes to user configurable sections of policy - but there still seems no benefit to your method -
1. they HAVE constrained there DEV changes to user configurable sections, and therefore they end up with DEV and TEST syned after the migration (as they would in the old model of pulling it out with GMU)
2. they had to make some change NOT in the configurable sections, in which case it is FUNDAMENTAL to the successful migration that this change IS migrated to TEST, and your solution will in fact not work at all.
I really don't think this has been thought through very well.