Once you make any change, even just "add another octet", you're into the chicken and egg problem IPv6 faced until recent years forced the hands of some ISPs. Given that IPv6 now has something like 20% adoption, there's little point starting over with something people view as simpler because of smaller changes to the written representation of addresses.
There is alot more changes then just an expanded space with ipv6
So while you may have a similar problem it would be FAR FAR FAR FAR easier for organizations to adopt an addressing system that works EXACTLY the same as ipv4 just with a larger address space
then all the other "improvements" they are forcing down everyone network (unwanted) in with ipv6
ipv6 spec caused all the problems by biting off more than what was needed to solve the problem.
Just start with 1::a: for the first 96 bits and duplicate the entire ipv4 range into the remaining sections (I.e. 8.8.8.8 would become 1::a:8:8:8:8) which would still leave a huge amount of space open from a's-f's being technically available as identifiers (i.e. 1::a:8:8:8:f would be a valid ipv6 address).
Then, as people stop using NAT, let them have access to the 1::b: section, and if that section ever gets filled, 1::c:, etc. Once NAT is sorted, roll out routers that would NAT ipv4 to 1::b: addresses so that they are in both locations at the same time.
It's easy enough to mentally switch to using colons instead of periods, and everyone could also easily memorize their opening "street sign" or whatever it is called.
Phase one has us use something in tcp headers, maybe something in the reserved area, to set a number. It's OK for that to just be maybe 1 to 4 even, or something small depending upon bit size requirements.
Since old systems won't use that reserved header space to determine anything, they'll ignore it. And new systems will exclusively use unroutable address space, like 240 being discussed here, for routing.
So old systems will drop the 240/ address space, but new systems will route it, as it will be 2.240.x.x.x. So only compliant systems will see the new address space ; the rest won't.
It won't help old systems, but it will mean new systems only using old address space, can speak to old systems, without breaking them.
Everyone loves sensible change, so unlike ipv6, ipv8 will only take 20 years! (What's ipv6 been out for, 25 years and not adopted yet?)
Rather than changing TCP, we could just make web browsers query SRV records to see what port to connect to. Then you could host 65535 websites on the same IP address, without requiring any software in the middle to check Host/ALPN/SNI. (The web is moving to UDP anyway with HTTP/3. Not saying the web is the only important part of the Internet, but it's a big one.)
IPv6 is kind of over the major adoption hurdle of rewriting all software to understand it. Nearly all software understands it. I'm not sure anyone really has the appetite for that again.
People like to make fun of ipv6 adoption rates but I'm pretty sure we'll all be dead and dust before srv becomes much more than a niche curiosity. It has similar chicken and egg problems but much less financial motivation behind it.
