>most have reached the conclusion that dual-stack is easier.
I know about the so called transition technologies and their dubious record, however the original context was "an alternative protocol backwards compatible with IPv4", not making IPv6 work on the IPv4 Internet. The former is possible (x) and was preferable circa 1996, while the latter are afterthoughts bound to fail: you obviously can't route true IPv6 on IPv4 hardware without upgrading it, and at that point, why not go dual-stack ?
Unlike a backwards compatible packet format, transition technologies require gateways to the "new" IPv6 Internet, that are checkpoints by definition and need configuration, resources and attack surface, amplifying the chicken and egg problem - why deploy gateways to the IPv6 when there's nothing there ? Add flakiness of the transition technology itself, for example Teredo clients can't even reach one other 25% of the time due to symmetric NATs.
(x) brain fart time:
If I were to redesign IPv6 today in a backwards compatible manner, I would treat the existing NAT hierarchy as a set of different routing realms, and upgrade only these points to do a stateless forwarding of the extended packets, while keeping their existing behavior for regular IPv4 traffic.
For example, to reach host 10.10.10.10 siting behind NAT 2.2.2.2, an IPv4 packet is prepared with an extension field :
IP Header: DEST: 2.2.2.2
Extended Header: DEST: 10.10.10.10, REALM=0
(src omitted etc.)
The IPv4 infrastructure will forward the packet blindly while the upgraded NAT/router will recognize the extended format and instead of dropping it will mangle it and forward it along:
IP Header: DEST: 10.10.10.10
Extended Header: DEST: 2.2.2.2, REALM=1
The destination stack will establish a connection if it recognizes the packet format, or drop it if it's a legacy IPv4 implementation.
You can repeat this for a bunch of chained NATs, incrementing the realm and swapping more routing bits from the Extended header into to the IP header, while reversing the mangling when extended packets exit from the inner routing realms. In an 128 bits address you could do this 4 times, sufficient even when dealing with something like "NAT44444".
So you can keep end to end stateless routability as long as all NATs are cooperant, and fall back to regular IPv4 over NAT when they are not. In time, NATs will transform to routers, simply mangling and forwarding extended packets and do less and less state tracking for legacy packets, until eventually tracking can be turned off.
The idea is to upgrade only key edge infrastructure (NATs), to do a very simple and stateless transformation, and not the whole Internet with a risky and complex technology. NAT clients are incentivised to upgrade (for p2p, voip etc.) without finding themselves in an Internet ghetto with high latency and routing blackholes. It's the same Internet with the same routes. In time, ISPs can release some of the massive SOHO IP space that's no longer justified.
Maybe not an entirely thought out idea, but it's a starting point. Or would have been. Despite it's troubled childhood IPv6 is of course superior, allows easy renumbering and real multicast, etc.