- You end up with a LOT of multisig (one per proxy) which is expensive to deploy and fill the blockchain memory … keep in mind that they will be disposable
You missed the point of UUPS hahaha. You wouldn’t really deploy the whole 734 every time, just deploy an UPPS and point to it.
The multisig owns no asset
But it manages a contract that has assets. It is able to implement 1077 with no trouble and ask the 725 to issue the repayment. All this while the other systems are completely unaware of what is really going on with the setup (734->725).
By calling the ERC725 proxy you would not be able to access info from the multisig.
As of now, it’s not part of the ERC725, and for that, I agree that it is not straightforward. But you could have an implementation of 725 that is aware of outside management, meaning another contract.
All this to say, that you really don’t need to resort to “state” resets.
Once a user deploys a contract with a vendor, they will be very limited on migrating it to another vendor’s implementation. Therefore, it makes sense that vendors will keep track (as they have), of their implementations, and when updates/upgrades are available they will have to check for compatibility. We can only try to make this less of a “locked with a vendor” kind of situation. And I think decoupling where possible, as 725 being simple but managed externally is one of those measures.