Great example of how fixing things "the correct way" does not seem to work sometimes.

They added those new addresses that can store more information.. but this requires a rewrite of old software to make it work.

If they used the old >bolting on top< method by extending ip4 from 4 octets to 8 (or more) octets, then old software could be extended much easier too / probably addresses could be simply mechanically translated too, so ancient software can work.

Actually no software rewrite is needed because the Berkeley Sockets API is agnostic to address format. If your software requires a particular address format, that's a bug. if you pass an IPv6 literal to getaddrinfo, you get a result with an IPv6 address structure and it tells you the IPv6 socket type you need to connect to it.

There is no space to put the additional octets. Supporting this would have needed a rewrite anyways. Nothing won there. They took that as a chance to improve the protocol overall.

Software availability isn't really the problem. For most software there was no change at all ("connect to that host" or "listen to any device" and operating system will handle details), most software which needed adaption had it for a while (picking up a devices explicitly, handling of IPv6 addressees, ...) while maybe not equally good (missing GUI improvements for better handling of IPV6 addresses)

The problems, as I observe, are more in network infrastructure, routing, etc.

I never heard this idea before, but more octets would be a lot prettier!!