True, the upcoming forks will increase calldata cost, which could produce more demand for a more size-optimized representation of ABI-encoded types. It’s still not clear by how much though. The heaviest users like L2s use blobs now anyway and gas is cheap. The current calldata layout is optimized for ease of decoding of deeply nested structures rather than size, but I could see it still being good enough due to other costs overshadowing it. I’d be careful with extending the language before the need is well proven because it’s something we won’t be able to just deprecate.
This is why I don’t think that Solidity is the place where we should start addressing this. The current ABI works because it is widely adopted by pretty much everyone who writes contracts regardless of the language. Things cannot be easily removed once adopted, while unilateral changes that are not adopted will always stay there as obstacles to composability.
My suggestion would be to start with an ERC. That should propose some specific alternative layout and back it with some numbers and reasoning for why it’s fit for the purpose. If the proposal is good I’d expect it to be picked up by libraries first for encoding/decoding to/from a bytes buffer. Then we can think about making it a part of the language.
BTW, you may want to look at Possible ABIv3 as default contract interface. This was an earlier proposal for a more compact, RLP-based encoding. Also the ABI v3 proposal in Vyper. These were aiming at replacing the default encoding, which is why they stalled in the end, but if you’d be interested in finding other people interested in standardizing a new set of ABI types, that seems like a good place to start.