Modern clients and servers get IP addresses in these new whole IP ranges and can communicate together.
Relatively easy to adapt the code of modern software also since it's about removing a restriction from a client-perspective.
Load-balancers and legacy clients use IP addresses from the old pool.
If you have Windows XP you can communicate only to legacy IPv4 (in practice only loadbalancers from Cloudflare, GCP, AWS and co) and your other legacy stuff. Others happily communicate together.
But no, we got this wonderful IPv6.
Sad because it was really doable, theoretical maximum below 512 GB of memory for routers to store the whole routing table, it's manageable, versus the 2.176×10^22 exabytes (!) of IPv6.
To store 999.999.999.999, then you are totally fine with a 64-bits INT (QWORD), and there is no struggle to backward-compatibility store a 32-bits INT (DWORD) into it.
It's more of a matter of doing #ifdef IPV4_EXTENDED #define DWORD QWORD #endif
and add an extra IP field inside the IP header packet itself that says, "this is the IPV4_EXTENDED DESTINATION 5-bytes IP", and the previous field is marked a legacy/deprecated.
In fact, it's quite convenient, since we are all INT64, sockaddr_in would largely fit in an INT64 for both IP itself and the other elements that are in the struct.
https://man7.org/linux/man-pages/man3/sockaddr.3type.html
5 bytes for the sin_addr field is enough to store until 999.999.999.999.
Gives you 3 bytes to store the port etc.
The networking APIs guys could be drinking cocktails at the bar by now, if they would change these types.
There is backward compatibility and smaller effort for a great impact, and this is beautiful.
It's actually beneficial for the majority of developers.
From the developer of Windows, to the developer of Age of Empires, to the developer of a CRUD app on the web (who stores IP addresses as a string or as an int), they wouldn't see too much struggle to port to int64.
Less than having to build a full new IPv6 experience.
In practice, client apps, at the time you open a new socket, if your lib says it wants an INT32 or an INT64 it doesn't matter for the developer of that app, since type is automatically casted.
time() had a similar situation.
We migrated by adding new bytes, we didn't redefine the concept of time.
From a developer-experience, "link to the latest version of the network library, oh btw, connect() accepts an int64" and remove the UI restriction of 255.
It could even be possible to give compatibility to very old software that we lost source-code from by overriding the network layer with LD_LIBRARY_PRELOAD or equivalent, and patch these softwares by manually NOP the right JGE instruction (the asm code for " >= " ) that checks if we are over 255.
