Honestly, the most useful way to think about this is comparing it to Jito, and the biggest thing to consider in terms of impact on the network is probably how it would affect Jito bundles, and downstream effects on products and libraries.

1. Yes. It unlocks a lot of functionality, and the lack of larger data creates a lot of avoidable inefficiencies around single-use data and atomicity. The reasonably widespread use of Jito bundles for activities other than sandwiching, like overcoming ix data limits for ZK, shows there is demand. It would generally be much more efficient to avoid the pattern of: open account -> accumulate single-use data -> use data in subsequent transaction -> close account.

2. Consider that a Jito bundle is basically a less efficient version of 5xTx, as in order to conform to the protocol, it is forced to do 5x the signature verifications with a 48-byte header overhead on each data packet, and at least one 64-byte signature and 32-byte pubkey for the fee payer of each transaction. To charge for bigger data, why not simply keep the same base cost of 5000 lamports per signature and add an additional 10 lamports per round of SHA512 after the initial 1-3 already included in the existing fee? One verification is about ~500x more expensive than a round of SHA512, so it is easy to extrapolate incremental costs (savings, in fact) to verification in this way. Don't add any additional compute/data/whatever budget instructions for data size. Existing priority fees and Jito tips already handle fighting over CUs pretty well.

3. Jito has proven that pseudo-5xTx is stable over a long period of time. If anything, as the majority of nodes are running the Jito client, the biggest question is probably "how are bundles impacted by this change?" A lot can happen in a 5x3xTx bundle, especially if compute limits are also lifted dramatically at the same time, however data and compute should really be addressed separately.

4. 2-3x is what's required for most useful cryptography. Jito has demonstrated stable 5x bundles for a long time. I don't see why 5x would not already be a reasonable baseline.

5. Implementation in Agave is straightforward. Jito protocol is a question mark. There may be some downstream effects on libraries or products that are built on the assumption of a 1232 (1280) byte limit, or the idea that 1 data packet = 1 TX.

1372 is common in many enterprises using mesh VPN, MPLS and variable other solutions in a limited environment with unknown 3rd parties. You can't always know what header space you'll need, so even with a year of SIMD in-view its difficult to anticipate precisely to the byte what is desirable vs needed.

I assume it's out of scope for this discussion, but jumbo frames (9000) in a modern cluster for local traffic and anything below 1372 MTU for the public interface should be part of spec/testing. If it's not, I hope somebody is ready to dump/capture the cluster traffic while testing this to avoid scope-limited visibility to stack stability issues.

1. Yes, Solana node operators should be capable of an MTU change and to anticipate fragmentation and bus bottlenecks on a node

2. Costs should have a dynamic min-max target, most easily led by XOR in the prioritization fee as currently active in memory. Rent could be assessed to anyone wanting routine priority by declaring that higher priority per account, effectively a personal gas station to sweeten a tx offered (a later tx could be designed to pay prioritization via rent but that should be refined in a framework of block height as time). I'm clueless about implementation here except to suggest that the change should not fetch/require remote data, meaning that node operators would have a "cool kid" list, which should probably have a high floor. Significantly busy accounts with logic would be the target consumer base, not regular human consumers. Maybe min floor is 1 SOL 🤷‍♂️

3. Tx size increase should be expected to reduce total throughput in bytes. Multiple conditions should be tested/toggled, including SFP NICs, jumbo frames in the cluster inside interfaces, Intel Optane and AMD Storemi (and without as control) and upstream packet fragmentation at common global numbers like 1492, or at least log MSS for PMTU discovery on tested nodes' paths to a public core network

4. The risk of issues for smaller, less competitive operators is to lose throughput significantly. If the loss can be minimized/optimized below 15% I think it's worth the trouble to try a truer-to-max size than doing incremental changes. I assume multiple values would test in the 1300 range

5. Change MTU size, test again, rotate conditions/hardware, test again. Repeat. I would not reccomend a larger change until a framework exists for utilizing rent as parked capital for priority tx. Bus bandwidth in the tested nodes should be scrutinized and logged

Atomic liquidations or one-click DeFi operations would benefit a lot from this - things where you have one token but the operation requires a different token input, swap + deposit (single-sided liquidity deposit), swap + leverage (sol long with usdc deposits), flash loan + swap + deposit (one click leverage or atomic liquidation).

Usually it works but requires extremely tight lookup table management with very low margin of error, there are usually 100 bytes left and therefore 3 unknown accounts that are not part of preexisting lookup tables, growing this would allow a higher margin of error and better UX and fewer errors.

If we increase the max size substantially it probably makes sense to have a seperate fee market for transaction size.

Right now a txn fits into a shred which maps cleanly onto a UDP packet or a single TCP packet inside quic. Would we change this so txn's span multiple shreds? What would we do signature verification on? If we increase the size of a txn, we create message fragmentation on the network. I agree completely there are many benifits to increasing the txn size but there are huge costs at the network layer we would need to address first

with the tpu using quic now, mtu is mostly irrelevant for solana application level packet sizes. if we're changing the tx limit, it should be bound by memory preallocation parameters. something like 4kB (one memory page) would make sense

the critical part of the discussion is if/how economics should change to account for additional load downstream

tl;dr: this is NOT a simple constant change