As a community, we have failed, because we never acknowledged and addressed the need for backward compatibility between IPv6 and IPv4, and instead counted on magic handwaving about tipping points and transition dates where suddenly there would be "enough" IPv6-connected resources that new networks wouldn't *need* IPv4 address space any more.
I’m not sure that we never acknowledged it, but we did fail to address it, largely because I think we basically determined that it’s “too hard”.
There’s really no way for a machine with a >32 bit address to feasibly/reliably talk to a machine that only understands 32-bit addresses short of involving some sort of intermediate proxy host doing some form of address translation. We’ve actually got LOTS of those solutions deployed with varying levels of success/failure/idiosyncrasies. I’ve spent a fair amount of time thinking about alternatives and admit that I, myself am stumped as to how one would go about this.
In doing so, we have sown the seeds of our own future pain and suffering.
Do you have a proposal for how this problem could have been/could be solved?
By allowing IPv6 to be defined and established as an incompatible network protocol to IPv4, we ensured that IPv4's future was assured.
I’d argue that we did much more to achieve that by deploying NAT. Absent NAT, we wouldn’t be able to pretend that IPv4 still works.
*Every* transition mechanism we have for networks today relies on having *some* amount of IPv4 address space for the translation gateway devices, which will continue to drive an ever-increasing demand for smaller and smaller chunks of IPv4 address space to be parceled out to every new network that wants to join the Internet.
Well, at least theoretically, that can end when a sufficient critical mass of the internet is reachable via native IPv6 that we no longer care about reaching the outlying corners that aren’t.
Let me ask you a slightly different question… Given a clean slate, what would you do differently so that a host with no possible capability to put more than 32-bits into the source or destination address field of a packet and no ability to look for address pieces elsewhere in the packet (i.e. a current IPv4 host without software modification) could talk to a host that doesn’t have a 32-bit address?
It turns out to be _REALLY_ hard to put more than 32-bits into a 32-bit field without loss.
Short of doing that, any translation mechanism is going to require some IPv4 address for the translation host (though it doesn’t necessarily have to be globally unique).
The only alternative is that web-scale companies like Amazon and Google stand up swaths of IPv6-to-IPv4 translation gateway boxes, and provide 6-to-4 bidirectional translation services, with some clever marketing person figuring out how to make money reliably from the service.
I’m not convinced this is the ONLY alternative, but it’s certainly one of the (sadly) less impractical ones.
At that point, new entrants could conceivably get on board the Internet with only IPv6 resources, with no need to scrabble for a chunk of ever-decreasing IPv4 space to perform the necessary gateway translation for their customers.
IPv4 is still relatively cheap at $50/address. The bigger problem, however, is that the people who need to migrate aren’t the ones paying the cost of failing to migrate. We’ve got an economy where the interests of the community are utterly divorced from the interests of those with no motivation to migrate to IPv6 and really, no way to provide that motivation through externalization of the cost.
I don’t know of a practical way to do it, but if there was some economic cost that could be imposed on entities failing to implement IPv6 in their products and services, I would be willing to bet that IPv6 uptake among the remaining IPv4-only entities would be greatly accelerated. Especially if that cost somehow escalated each year they failed to act.
Unfortunately, because it's not just a mapping problem but an actual packet-level incompatibility, the companies providing the magical bidirectional translation service are going to be in the pathway for the entire bitstream, making it a bandwidth-intensive product to deploy. 
Frankly, this almost certainly ends up being something that needs to be deployed close to the edge by two classes of entities:
1. Eyeball ISPs that have customers that can’t go IPv6-only.
2. Content providers that don’t provide native IPv6.
Again, this comes back to the economic issue I’ve described above. Plenty of incentive for 1 and really, that’s no worse than CGNAT and is already being done by some, but for 2, so far, at least, that group has been able to externalize the costs onto everyone else by forcing them to figure out how to continue to preserve access to their IPv4-only content instead of having to adopt IPv6.
Since it costs them nothing to ignore the plight of the eyeball providers (and sometimes may even provide an advantage), the economic incentives run contrary to the common good and we are where we are.
On the plus side, they'd have the best view into everyone's traffic one could ever hope for. Forget just seeing DNS queries--you'd have visibility into *everything* the users were doing, no matter how tiny and mundane it might be. Imagine the data mining potential!!
Well… Metadata at least… Unless everyone gets stupid enough to do stuff in clear text, all you’ll really know is flow sizes, rates, source/destination IP pairs, etc. You won’t actually get to peek at the content except for the people stupid enough to do anything in today’s world without end-to-end encryption.
If I were younger, stupider, and much, much, MUCH richer, I might start a company to do just that...
It’s certainly monetizable data, but trying to do that if you’re not somehow able to offer it as an appliance that you deploy into groups 1 and 2 above as a service (and somehow incentivize group 2 to accept your appliances), success remains “unlikely”.
Owen
