Right, it only converts to v4 if both src and dst are 32-bit, which is fine in v4.1 too. Everyone can adopt v4.1 hardware/software without even thinking about it but hold off on using >32-bit addrs until they feel like enough peers are on v4.1. Yes it's only a one-way compatibility, but that's way better than v6 which is incompatible both ways, creating gridlock.

If you really want extra compatibility, idk if this is a good idea but it's an option... Go v4.1 using up to 40-bit addresses for now (but leave room for more). Translate a v4.1 TCP/IP packet with a 40-bit src and 32-bit dst to v4, truncating the last 8 bits of the src IP, provided the last 8 of the src port matches them. IPv4-only dst can respond fine. When that /32 v4.1 router receives the v4 response, set the last 8 bits of the dst IP to the last 8 of the dst port. So it's kinda like NAT except translating to a public /40 IPv4.1 instead of a private IPv4. And you just speak v4.1 without all this if the dst is >32 bits.

I think you underestimate the complexity of deploying a new protocol like that.

Also, you know NAT64 exists, right? You can have a v6 only network connecting to v4 hosts. Is that not enough compatibility if you don't want dual stack hosts?

I can't tell you the man-hours, but I can tell you it'd be easier than ipv6. And yes I'm aware that you can give a "v6 only network" a v4 address, which means you're still on ipv4.

(ipv4.1 could also be implemented using the ipv6 header, btw)