The question of how long we allow standards proposals to 'own' an area without evidence of success is an important one. I have put a lot of work into S/MIME over the years. I can't say that the rate of adoption shows that S/MIME deserves to 'own' end to end secure messaging. OpenPGP isn't any better in that respect.
Technology changes over the years and so do technical constraints. I was taking a look at QUIC the other day and considering how it would likely perform if it was implemented with the tools we had in 1993 when we were building the Web. We didn't stick with TCP out of misguided anything, TCP was the only way to get the necessary performance at the time because the only way to get performance was to put the transport handler in the kernel. UNIX didn't really have threads at that point, there was a POSIX spec but that wasn't really implemented (guess how I know).
But what if the same transport-outside the kernel approach was applied to IPv4 address exhaustion? What if we considered that the problem of the day rather than 'deploying IPv6'?
Consider the fact that there are almost as many IPv4 addresses as 32 bit ASNs. So as far as the ability to send packets via distinct goes, IPv4 isn't intrinsically so different from IPv6.
People have suggested various prefixed routing schemes over the years but this never got anywhere because they are all 'IPv6' complete, that is, they all require the same degree of infrastructure changes as IPv6 does.
But if we consider application layer implementation, an address prefix could be pushed into the IP packet payload. The only change we require to make use of such an addressing scheme would be a DNS address record (APLUS) specifying an IPv4 address and a binary prefix to be prepended to the start of every packet and an application library capable of supporting it.
Of course there are huge sunk costs in IPv6. But at what point do we decide its time to give other approaches a try? After all, one of the best ways to spur deployment effort is sometimes setting up a rival effort.
