Because even in 2000-2004, when people starting more seriously talking about adding IPv6 support, BSD Sockets stupid legacy of having every user deal with gory

Because even in 2000-2004, when people starting more seriously talking about adding IPv6 support, BSD Sockets stupid legacy of having every user deal with gory details of used protocol made people write new software using gethostbyname(3) and connect()/listen() calls that used hand-written IPv4 parsers and artisanal sockaddr structs. And there's a lot of software that never got corrected, that explodes when it reads an address that isn't IPv4 even if uses a more modern API. Meanwhile IPv4 was supposed to be sunsetted in 1990, had been actively pushed to be migrated off in 1990-1995, but the cost of updating software that used the popular BSD Sockets API, introduction of NAT to remove major pain point, and certain major client (read: government and military) giving waivers on upgrading deadlines to vendors[1] meant that nothing really moved. And everytime people try to push things forward, some big chunk of infrastructure becomes a blocker - like cloud providers[2] - or we get inundated with "why in 1995 they didn't decide to go with something backwards compatible?". Newsflash - it was impossible for BSD Sockets software to be forward-compatible. If your software was build with XTI or similar interface (like Plan9's dial(), which is present in Go), you got IPv6, IPv7, and IPv9 support back in 1996, along with X.25 and who knows what else. In fact, IPv9 aka TUBA was actually implemented in network hardware around 1992 - the original RFC pointed to experiments using nearly unmodified Sun and Cisco hardware. [1] US government finally learnt though, and if you're selling to them you now have to support v6 or wrap your product in a black-box that will handle v6. No deferrals for products/vendors. [2] I'd argue AWS, GCP and Azure had significantly hampered global IPv6 migration