I propose the Willis law (are you aloud to name a law after yourself?):

The spread and reach of TCP/IP will accelerate at a pace faster than that of the transition to IPv6 indefinitely, therefore we are saddled with IPv4 until the end of time.

In fact, we know that IPv4 lives in the observable universe. You can travel at the speed of light towards IPv6, but the expansion rate of space time-itself (you can think of space-time as a series of tubes) is not limited by the speed of light. Thus, IPv6 is only theorized to exist, in order to explain other physical phenomena. Worse, even if it was proven to exist by a distant observer, there no way for them to relay that information back to us because our routers here at earth would drop the packets.

It's just plain cost. Reworking things takes engineering time, an engineers need to be paid.

If I were to list impediments to the technical development of the Internet, local telco monopolies would be much higher in the list, but it's another kettle of fish.

People wanted to change bitfield with version from 4 to 6 and increase amount of bytes in IP address filed. Simple KISS.

Instead of that we got fragile, backward incompatible, unnecessarily complex, jack of all trades protocol. And people are surprised that even after decades since the release of IPv6, it is being avoided like a plague.

Consider that NAT64 is able to translate between IPv4 and IPv6 at the packet level. If the protocols were as different as you suggest, this wouldn't be possible.

Doesn't IPv6 remove broadcast, thus removing DHCP and ARP?

I mean, hosts need to be 'dual stack' to support IPv4 and IPv6 together - whereas TheLoafOfBread's proposal would allow support of both with one backward-compatible stack.

DHCP and ARP use 32-bit addresses, so those protocols had to change regardless.

I would challenge you to find someone who knows the difference between Ethernet broadcast and multicast without looking up the answer. They are very similar mechanisms.

NAT64 is never in a position to need to translate DHCP & ARP, those live fully on one side of NAT64 ("4" side for DHCP & ARP, "6" side for SLAAC/DHCPv6 & NDP).

NAT64 is involved on the level of TCP & UDP, not lower level protocols.

This comes up often. What do you think would happen if you sent a “IPv4+” packet? All the ossified equipment would drop it. So you have to replace all this equipment, ideally _once_ so we ought to make it count.

The main issue with IPv6 adoption is people who didn't learn IPv4 before NAT, and want to use the hammer (IPv4 NAT) for everything.

A hammer working fine today, that you own, is better than a machine tool tomorrow, that you'll have to pay.

I wish we had an idiom for this. Maybe something bird-related.

Also, developers who don't know how to get their daemons to listen on multiple interfaces at once.

That's not necessary; listening on the wildcard IPv6 address without the "IPv6 only" flag enabled on the socket is enough. A IPv4 connection arriving at it is mapped to a special IPv6 address, so the code doesn't have to care about IPv4.

Unless you were using Windows, where IIRC the IPv4 and IPv6 stacks were separate, and a single socket couldn't be used to listen to both at the same time. (This might already have been fixed in more recent Windows releases.)

I'd say that it's not that there's some gain causing people/organizations to be obstructive, but rather that IPv4 and its address shortage simply isn't a problem for the influential people and organizations, they're doing just fine and for them there is nothing that needs to be fixed; IPv6 is needed by "someone else" who can be safely ignored with no noticeable effect to the bottom line.

IPv6 lacks back compatibility with the current standard. It cannot succeed.

It doesn't there are millions of IPv6 only devices that can connect to IPv4 only sites. See US mobile carriers.