alt Hacker NewsBut v6 did most of what you're asking for there??
It has "IPv4-compatible IPv6 address"es: https://datatracker.ietf.org/doc/html/rfc2373#section-2.5.4, and then a way to get them over networks where not every hop supports v6: https://datatracker.ietf.org/doc/html/rfc2893#section-5. You don't need new DNS or DHCP to use these, or SLAAC. There's no anycast relay. They can go over v4 hops.
Why spend all this energy complaining about v6 not doing something that it did do?
> The later stage of migration should just be that people start using longer addresses given that both ends are v6 and DNS etc supports it then
It seems your only real problem is that you completely missed the early part of the transition. We've been in what you're calling the later stage for twenty or so years now.
IPv4-compatible v6 address was only for dual-stack hosts talking over a v4 network. They still had their own v6-native addresses that they had to use if they wanted a v6 network. So this isn't what I described where the v6-native route is the same as the v4 route, or a superset in the later stages (shared down to /32, v6-only in deeper subnets).
The thing I want to solve isn't just v4 routers in the middle, that's more of a bonus. All the routers between my machine and any service probably support v6 anyway, but a bunch of services are v4-only because of the migration effort. They should be able to turn on v6 without having to change everything about their networking.