Ignoring your weird fetish to bash SegWit, if we some day end up doing a hard-fork there is a lot of ideas that can be implemented to "make tx lean" or better say compress them. For example right at the beginning of each tx there is 4 wasted bytes for version which is completely useless!
not useless.. just not yet utilised
as you know things like mid transaction opcodes allow things to change
after the opcode to new formatting based on rules of expectation
after the opcode
and like this, the first few bytes of a tx can be used to introduce new things for the entire transaction format, from the beginning
EG
the spending UTXO
imagine transactions are no longer identified by a TXID in SHA256 (32bytes)
but instead hash160(20 bytes)
by using a new versionbit at the start the network can make new nodes validate transactions via a new TXID that is shorter. thus savign 12 bytes per input
heck what if due to blocks immutability instead of UTXO being TXID, they instead just ID'd a tx by blockheight+tx position in block+output position in tx
EG
3byte block height (16777215 blockmax (319years))
2byte tx position in block (65535tx per block)
1byte output in tx (256 outputs per tx)
thus a UTXO id can be as small as 6bytes
also knowing not everyone will spend 8bytes of output "value" meaning max
18446744073709551615
184,467,440,737btc 09551615sats
it doesnt need to represent 187Billion btc(21m limit after all)
heck no one is going to move 3million in one output so this could go to 6bytes
2,814,749 76710655
thus saving 2 bytes per output
the first bit of a tx can actually be utilised in the future. so saying its useless is not correct.. it simply has not been used yet.
..
also this version bit can be used in different ways such as users own tx can use it as a flag bit for voting
..
but yes them 4 bytes, allowing for 4,294,967,295 different transaction versions. is too many future options
this could also be reduced to 1 byte of 256 versions of future options, seeing as how the tx version is after 15 years only at version 2