No. The NAT64 hack involves intercepting the DNS requests and rewriting the IPv6 packets in flight so that the IPv6 only clients see outside IPv4 hosts as IPv6. Among many issues, it breaks any end-to-end encrypted protocol that includes IP literals, such as FTP and SIP.
Also, NAT64 presents no immediate benefit to a client upgrading in a IPv4 only environment, since it still doesn't allow two clients behind NAT64 gateways to connect to each other if there isn't an IPv6 connection between them. So the same old IPv6 self-fulfilling tragedy, everybody must upgrade before anybody can see any benefit, therefore nobody upgrades (or uses NAT64).
The main benefit of a backwards compatible packet format is that IPv4.1 islands see each other from day one in the legacy IPv4 internet and get the full benefits of the new protocol, without any configuration or tunnels. The "encapsulation" seen by legacy hops is in fact the canonical, definitive packet structure, there is no temporary transition technology that can break or needs to be configured.
> the problem of IPv4 clients trying to connect to servers with only IPv6 addresses
This is not a problem that can or should be solved, and it's not the problem significantly preventing IPv6 adoption. A non-upgraded client will just see an IPv4 internet, just like an USB 1.0 won't be able to use USB 2.0 speeds.
The difference is that, while a software&hardware upgrade to IPv6 won't bring you any new connectivity without extra configuration from your upstream provider, an IPv4.1 upgrade will instantly allow you to see (and connect end-to-end) to all existing IPv4.1 islands and hosts, using only your legacy, IPv4 connection. The hierarchical extended address space (IPv4 subdivisions) is immediately available, incentivizing adoption without risking connection issues, while the upward extended space becomes available when you have a native IPv4.1 connections, just like with IPv6.
1. If you want the solution of IPv4 packets being a subset of the address space of IPv6, your options are rather limited in regards to tampering with the original packet. IPv4 hosts can't deal with the larger addresses of any IPv6 hosts they're talking to.
2. Of course there's no immediate benefit for IPv4 clients - there isn't in your proposal either! It's a compatibility measure, allowing IPv6-only clients to talk to IPv4 servers. (I make that distinction because under no scheme can an IPv4 host initiate a connection to a host with no IPv4 address.)
3. I have no idea what you're talking about with the idea that NAT64 requires IPv4 clients to talk to each other over an IPv6 subsegment. I suspect you're thinking of a different transition technology solving a different problem. NAT64 provides a virtual IPv6 subnet containing the entire IPv4 address space. IPv6 clients can send packets to this subnet, at which point they are routed to the nearest NATting gateway and passed into the v4 internet after packet rewriting.
4. FTP and SIP containing IP literals is an irreducible incompatibility, which cannot accommodate an address size change without intrusive packet rewriting anyway.
What hardware, especially ASICs, do not support wire speed IPv6 and have not for a decade or two?
T-Mobile was gave a presentation on going IPv6-only in 2017:
> For the past 10 years T-Mobile has worked towards creating an IPv6 environment and we are now getting very close to our goal. Stephan presents learning on how to successfully enable IPv6-only using DNS64 with or without 464XLAT. He will do a live demo of the different IP interfaces on an Android handset. Finally, he will discuss and give some best practices on how to handle DNS, applications, and websites that are having issues with DNS64.
Any hardware router introduced in the last two decades has IPv6 support; in my somewhat outdated experience the barrier to implementation is implementing dual-stack logic in software built for single stack.
ISPs in Belgium implemented IPv6 a decade ago (some even two decades). ISPs elsewhere could have done it too by now (nobody is still using 10+yo hardware, I hope...).
The backwards incompatibility is irreducible, inherent to the special place of Layer 3 in the networking stack.