User configuration change after package upgrade

I know that will sound like a deja-vu for some of you (we did discuss about it at UDS Brussels IIRC), however I think the situation nowdays will make it more needed than what it was in the past.

Sometimes, we need to change/update some user configuration on upgrade. However, as everyone knows, the upgrade/installation phase is proceeded by root, so we dont have a sane and secured access to all user data on this machine at this particular time.
Of course, there is still the gold rule "don't change user configuration on upgrade" that we try to keep as much as possible, and in this case, changing the gsettings default is just enough most of the time. However, some cases are still valid and changing the gsettings default doesn't work, on top of my head:
- Unity launcher icons. Some softwares renames their .desktop file name (ubuntu one for instance) in newer release. The key for those icons are put together in a list ["firefox.desktop", "ubuntuone.desktop"], and so if ubuntuone.desktop is renamed after a system upgrade, the launcher will just drop ubuntuone.desktop but not showing the new one. An upgrade to detect that case and replace ubuntuone.desktop with the new name will be handy.
- We got the glorious example on compiz in the past. Fortunatly, this one will soonly be fixed with the case of gsettings, but we surely do have other similar cases when a default is reset to the default and not considered as such.
- Even if compiz is fixed, we needed to change the default plugin list more than once, depending on which profile is running, that's another use case.

So, I want to open the discussion on how to do this in a light and harmless way (no python for instance ;)). Stamp that a migration happened. Should this be some triggered by client packages themselves? When should this be run in the session? and so on :)