EIP-3074 alternative via transaction type

Specification

Add a new transaction type, which is an EIP-2930 tx but adds two new fields:

A string of contract_code (can be a delegatecall forwarder, to save bytes)
A signature (standard v,r,s)

At the start of executing the transaction, verify that the contract code of the signer of the signature is empty, and set it to contract_code. At the end of the transaction, set the code back to empty.

Note that the signer of the contract_code signature, and the tx.origin of the transaction, are allowed to be different.

Conversion of EIP-3074 use cases

In this EIP-3074 alternative design, AUTH and AUTHCALL would get replaced by calls into the EOA. Specifically the intention is that the contract_code would be a user wallet, and would expose two functions, verify and execute.

AUTH would be replaced by a code to verify, which would use TSTORE to locally set authorized[msg.sender, ...] = True.
AUTHCALL would be replaced by a call to execute, which would use TLOAD to verify authorized[msg.sender, ...], and then execute from there.

Hence, there is a very simple transformation from "existing 3074 workflows" into workflows under this new scheme.

Benefits

As mentioned above, this seems like it is compatible with any 3074 workflow, and it would require fairly little work to convert 3074 workflows. It has the added advantage that it is very forward-compatible with endgame account abstraction, without over-enshrining any fine-grained details of ERC-4337 or RIP-7560.

Specifically:

The contract code that users would need to sign could literally be existing ERC-4337 wallet code.
The "code pathways" that are used are code pathways that would, in many cases (though perhaps not all), continue to "make sense" in a pure-smart-contract-wallet world.
Hence, it avoids the problem of "creating two separate code ecosystems", because to a large extent they would be the same ecosystem. There would be some workflows that require kludges under this solution that would be better done in some different "more native" under "endgame AA", but this is relatively a small subset.
It does not require adding any opcodes, that would become dangling and useless in a post-EOA world.
It allows EOAs to temporarily convert themselves into contracts to be included in ERC-4337 bundles, in a way that's compatible with the existing EntryPoint.
Once this is implemented, EIP-5003 is "only one line of code": just add a flag to not set the code back to empty at the end.

Weaknesses

It likely inherits a lot of the criticism of 3074 on the grounds that there are specific pieces of code that users would trust, and wallets would manage these pieces of code, and "who can create by-default-allowed pieces of code" might become a centralization vector. However, it feels like any EIP that attempts to handle the "privilege de-escalation" (aka sub-keys) use case of 3074 would have the same problem.

Open questions

Should the contract_code signature also sign over the account's nonce?
Should the contract_code signature also sign over the CHAINID?
Should there be a list of (contract_code, (v,r,s)) pairs, to set the code of multiple accounts? This could save gas for batches.