We’re looking to adopt EIP-6551 for mech and I started catching up on discussions here. 
We modeled the API of our execution interface after Safe where transactions are defined with the following parameters:
address to
uint256 value
bytes memory data
Enum.Operation operation // 0 = call, 1 = delegatecall
Support for delegatecall seems important to us (e.g.: for batching via multi-send), but it also comes with the implication that we cannot prevent account owners from writing to their TBA’s storage. Account implementations that allow generic delegate calls are implicitly upgradable with storage-based proxies.
That’s why I would like to suggest reconsidering this change:
The Registry now deploys ERC-1967 proxies instead of ERC-1167 proxies. This change increases compatibility with existing proxy detection infrastructure since ERC-1967 proxies can be detected by reading a storage slot rather than pattern matching against bytecode. This change also allows wallet implementations wishing to implement upgradability to do so without requiring an intermediate proxy.
I feel ERC-1167 proxies are better suited for the following reasons:
- Implementation immutability, even if an account allows for generic delegate calls
- Lower tx execution cost (no storage read)
- IMO, they are common enough so that we can assume good support from proxy detection infrastructure.
Due to the nature of TBAs being transferred between people, immutability of the account implementation seems paramount for establishing trust.