I have a few thoughts on how the existing (legacy) transaction format should be handled in this EIP.
1. Should the protocol continue to support the legacy transaction format?
I believe the answer is yes, but with some caveats. There are many existing tools that have been built for this format and it is unreasonable to deprecate it without a warning far in advance. However, I don’t think that the legacy tx format should be supported at the protocol level (devp2p). Hard forks are inherently not backwards compatible, so there isn’t an advantage of continuing to support them at that layer. The only caveat is that the 0 tx type must continue to follow the legacy hashing format (e.g. the tx hashed as it is now, without the tx type) so existing signing tools don’t need to be updated. By completely removing the legacy tx format, txs can be decoded without relying on a “high bit” since a client will never expect the first element in a tx to be anything other than a tx type identifier. We can lean on the clients’ RPC endpoints for support in this transition. For example, all endpoints can continue operating as they do today and accept legacy txs as input, then transform them into a typed tx or filter out non-legacy txs for outputs, then strip them of their tx type. An optional flag can be added to the endpoints to denote whether the requester would prefer to send / receive transactions encoded in the typed format or legacy format. This will allow backwards compatible to be maintained with existing tools.
2. Should the legacy transaction format ever be deprecated?
Since the protocol no longer recognizes the legacy transaction format, I don’t see any reason to not put an end-of-life date on it a few hard forks in advance. This will give teams enough time to update their systems to support the new tx format, at which point the tx hash logic can be updated for 0 typed txs to follow the standard procedure.
3. Should transactions be in a two element “envelope” structure?
I argue no. Because I don’t believe there is a need to continue supporting the legacy format, there is no advantage of the envelope structure versus a flat structure. When decoding, clients will always expect the first element to be the tx type. The flat structure will be simpler to reason about and will save a few superfluous bytes denoting the length of the enveloped list.