As part of the EIP-4844 discussions, the topic of type-5 0-blob transactions came up repeatedly.
One problem with 0-blob transactions is that eth/68 does not allow distinguishing between transactions containing blobs and some that don’t, so 0-blob transactions would be treated as if they had blobs on the networking layer (use of wrapper type, Req/Resp, no rebroadcast on reorg).
Similar issues could reoccur with future transaction types. The EIP-2718 transaction type has never, conceptually, determined the networking and mempool behaviour when processing a transaction. What it does define, is the actual encoding of the transaction itself (globally, including GetBlockBodies), and the mechanism used for deriving the originally signed transaction hash and the perpetual transaction hash.
As eth/68 intends to change the transaction processing behaviour solely for transactions in the transaction-pool and local transaction-journal, I don’t think that the EIP-2718 transaction type is a good fit to encode that information. Instead, a separate field in eth/68 would make more sense to denote the (temporary) behaviour of affected transactions while they sit in one of those pools. Once a transaction is included into a block, none of that temporary behaviour should remain encoded.
Example how eth/68 could be defined (different designs possible):
NewPooledTransactionHashes (0x08) := [
[txtype₁: B_1, size₁: B_4, txhash₁: B_32], # no blobs
[txtype₂: B_1, size₂: B_4, txhash₂: B_32, num-blobs₂: B_1],
...
]
PooledTransactions (0x0a) := [
request-id: P,
[
[tx₁],
[tx₂, SSZ.encode({blob-kzgs₂, blobs₂, kzg-aggregated-proof₂})],
...
]
]
This way, the special Req/Resp gossip behaviour for transactions containing blobs could be triggered by presence of the num-blobs field, instead of based on the TX type, and 0-blob type-5 transactions would no longer be a special case.