Yes this would work!
Yeah this is unfortunate, I think it makes sense to prioritize keeping that code sequence short. Another alternative could be to switch back to returning 0/1 (0: success), and instead of returning the status code immediately from the *CALL instructions add a separate opcode CALLSTATUS to put it on the stack if necessary. I assume it will very rarely be used anyway?
As a side note, in EIP-7069 it’s really not clear to me when the failure status 2 will be returned on the stack. I can’t find a definition of “failure”. This part in particular confuses me: “9. Fail with status code 1 returned on stack if any of the following is true […]”, is that correct or is it an error and it should return status 2?
Regarding another point:
EOF1 contracts can only
DELEGATECALLEOF1 contracts
Is this restriction still necessary given that SELFDESTRUCT has been mostly neutralized in EIP-6780: SELFDESTRUCT only in same transaction?
There is a potentially severe failure mode for EOF upgradeable proxies: if the proxy target is upgraded from an EOF to a legacy contract, and the upgrade logic is located in the target, the proxy becomes frozen and unusable. This error could be prevented by having the upgrade code always test that DELEGATECALL works, but this seems like a footgun that should be avoided from the outset.
The rationale proposes this restriction as a way to prevent attacks/errors like the Parity Multisig, but actually introduces a new way in which a proxy contract could end up irrecoverably broken!