I don't know about V7. But at the same time that V6 work was started, there was also work on a V8 system.
V8 was based on master regional gateways, if I remember correctly, called stargates. The central assumption in V8: Throw away the assumption that a single IP address always refers to the same machine everywhere. Within a single region, there is a mapping from name to IP to machine. But that mapping does not hold across stargates.
If I want to talk to a machine in my region, then getHostByName() returns an IP address that maps and routes just as normal.
If I want to talk to a machine in a different region, then getHostByName() returns a special 4 byte magic token that talks to the stargate that sits between me and whatever it takes to get to the destination.
It is another level of routers. Just as now, I can work within my regional area network -- perhaps I'm a comcast customer talking to another comcast customer -- or, I can go out over the "backbone" of routers that talk to routers with the special gateway router protocol (sorry, I forget the exact acronym -- BGP, I think?) to reach the final region for "last mile" delivery.
This extends it another layer. But at the same time, each region now has an independent IPv4 space.
Want to really enforce a "firewall of china"? V8 would actually permit it. If something like this was in place, then any attempt to talk to someone outside of china would have to send that hostname to a central authority router, which could then return either an accepted "cookie" (looks like an IP address, but treated special by the routers), or "no such host", or "here's the government re-education website".
What is the major compatibility problem? It is suddenly impossible to cache the outcome of "getHostByName()" across runs -- the cookie returned only has a lifespan as determined by the gateways.
There is a much better, much deeper question to ask.
** WHY THE BLEEP ** are we still using things like getHostByName()?
Why the bleep do we still expose struct sockaddr to programs? It's an OS internal.
Way, way, way back when, before there was an internet, when arpanet was just one of many networking protocols in use, networking changed far faster than BSD releases could come out. So a bunch of stuff that should have been OS internals were exposed, so network drivers could talk to application programs without an out-of-date kernel in the way.
Today, that should be gone.
Today, there should be a simple open() call that returns a network connection -- and for simple TCP streams, that's all you would need. Message-based (UDP/etc) would probably have a flag on open, just as we have for "read only", "create if not found", etc, there might be "best effort only". Heck, imagine a file system that could recover from "out of disk space" by eliminating old "best effort" files automatically. Sure, put up a warning on the console -- but programs can keep running.
All the issues we see from "How do we re-write all those programs from v4 to v6", all those "how do we migrate X from 4 to 6", etc. -- all come down to "Why do we even care?"
This is serious.
Why worry about the program ever knowing what address to talk to?
Why worry about the program ever knowing that port X is the destination?
Why would you ever want to say "This program/server can only run once on this machine because the port number must be reserved and known ahead of time to the users"?
Why not just say "Give me a channel to service X running on machine Y", and not worry about "I want a TCP channel over 4 bytes of address".
Why worry about "Hey, the TCP protocol fails spectacularly over networks that have a very high bit length wire" and "well, we'll fake the TCP protocol with a new one that looks sort-of like TCP, can handle high bit-length wires, but can be reset by a random packet from an attacker with a 1-in-4 chance of success". (High bit length wires == satellite links. TCP has a packet size, and a window size; put them together, and a bare TCP connection over satellite has to sit and wait for acks a large amount of the time.)
Get rid of struct sockaddr
Get rid of a program's need to even care what the underlying network protocol / address family is.
Then see if there is any need to worry.
Last I checked, there was no way for a V4 only machine to talk to a V6 only machine -- while the original V6 address space map included the V4 address space as a special segment, that was removed in a later revision. If this is true (I don't know, it's been years since I've checked), then since there are lots of v4-only hardware devices out there, V6-only systems are DOA -- and we'll never be rid of the V4 legacy.
Is that still the case? Has that changed?