You can tunnel IPv6 over IPv4 (which is how the very first deployments worked).
And I think 6to4/6rd worked pretty to close to what you suggest: Each IPv4 gets assigned a block of IPv6 space which gets tunneled over IPv4.
> I think 6to4/6rd worked pretty to close to what you suggest: Each IPv4 gets assigned a block of IPv6 space which gets tunneled over IPv4
No. Tunnels encapsulate IPv6 traffic but they need to be set up, I need to know a gateway that is willing to take my traffic, decapsulate it and place it on the IPv6 internet. There are many reasons this is bad idea, it won't ever scale, it's fragile etc. 6rd doesn't improve things significantly.
A backwards compatible packet format will allow you to connect directly to IPv4.1 islands, without any configuration or choke point: the packets you place on the wire have the final extended structure, even if they appear as encapsulation to the legacy IPv4 hosts in the path.
It's as if any IPv6 host on the internet is guaranteed to have its own 6to4 gateway, and the encapsulation just happens to be the exact IPv6 packet / IPv4 compatible structure that you use to connect to any other non-gatewayed host.
Windows actually used to have 6to4 setup by default in the past.
There is no need to manually configure anything since the 6to4 have a globally unique anycast address and the ipv6 space is just derived from the own IP address.
Of course NAT breaks that if used on some box behind the router (also would break your proposal I think?) and there were a few issues with 6to4 (random people running gateways? who deals with abuse?) that lead to the development of 6rd (and which was used by a few fairly large ISPs).