My impression (from seeing IPv6 support projects being regularly deprioritized at a previous employer) is that it's more of a market/deployment problem than a technological one. Layer 3 is a uniquely annoying place in the current networking stack, in that changes to it are useless until everything on the path between you and the other hosts you talk to speak IPv6.
With upper-layer stuff like HTTP2, you can get some return on your investment as long as two hosts that want to talk to each other, however distantly separated, speak the new protocol/features. With lower-layer stuff like 802.11ac or 1GB ethernet, you can get most of the benefits just by upgrading the client hardware and infrastructure in a local setting. If you want to talk over IPv6, though, you need to upgrade clients, local infrastructure (e.g. in-home routers, corporate IT equipment), carrier routers, datacenter routers, and servers. In many cases, each of those things is controlled by a separate organization, and none of those organizations gets any benefit out of implementing IPv6 until everyone else along the chain does so too.
For example - let's say that you're providing some kind of web app or service from your own servers. There's a non-zero effort involved in setting up IPv4/6 dual stack throughout your stack, so you first check if you can even get IPv6 connectivity. Using EC2? Nope - no IPv6. Using a leased server in a colo? Pretty good chance they'll also not even have it available as an option. So at that point, why even work on this feature that you're not going to get to use, and that since it's not exercised by real traffic will probably be full of bugs?
And we can't simply dump the whole v4 range into a sub-section of v6 and call it a night either.
While it may work for the v6 side, the v4 side will have a hell of a time talking to anything on the v6 without some kind of network level NAT going on...
This is actually quite widely used (see [1]). The big limitation is that all connections have to be initiated from the IPv6 side, so it's usually used to allow v6-only client networks to access v4 servers, but even that is a big win for bootstrapping - for example, it's let T-Mobile configure all its new Android devices for IPv6-only behind a variant of NAT64.
Another cool trick is IPv4-mapped IPv6 addresses [2], which lets userspace software act like the IPv4 internet is just a subnet of the IPv6 internet, and speak IPv6 only, while the network stack of the host system deals with the annoyances of dual-stack. (In fact, I think on Linux systems this will even let you pretend that an IPv4-only configuration is actually IPv6 ;-) ).
With upper-layer stuff like HTTP2, you can get some return on your investment as long as two hosts that want to talk to each other, however distantly separated, speak the new protocol/features. With lower-layer stuff like 802.11ac or 1GB ethernet, you can get most of the benefits just by upgrading the client hardware and infrastructure in a local setting. If you want to talk over IPv6, though, you need to upgrade clients, local infrastructure (e.g. in-home routers, corporate IT equipment), carrier routers, datacenter routers, and servers. In many cases, each of those things is controlled by a separate organization, and none of those organizations gets any benefit out of implementing IPv6 until everyone else along the chain does so too.
For example - let's say that you're providing some kind of web app or service from your own servers. There's a non-zero effort involved in setting up IPv4/6 dual stack throughout your stack, so you first check if you can even get IPv6 connectivity. Using EC2? Nope - no IPv6. Using a leased server in a colo? Pretty good chance they'll also not even have it available as an option. So at that point, why even work on this feature that you're not going to get to use, and that since it's not exercised by real traffic will probably be full of bugs?