*ANY* physical change to IPV4 breaks IPV4. Given that assumption, we may as well start from scratch, and go back to square 1 when designing IPV6.
Well, that's not really true (both of those). IPv6 addresses are their own namespace, and can't communicate with IPv4 addresses automatically. Think of how FAT got long filenames ... or how DNS grew extra TLDs like .info ... or how MX and SRV records in DNS started showing up, although using regular A records for mail and other services still works.
If you extend IPv4 in a clever way, rather than rewriting the whole thing and coming up with a new address space, you can increase adoption because people don't have to get everything upgraded end-to-end to make your system work.
Here's an example of such a scheme. Let's call it IPv4+. I'm going to say that it uses 64 bit addreses (but only because that's convenient). The first 32 bits are an existing IPv4 address, and if you own a single IPv4 address you own all 2^32 IPv4+ addresses that start with the IPv4 address. Allocation works as normal, etc. Maybe for good measure we'll take an IPv4 class A (1.x.x.x?) and reserve it _just_ for IPv4+ allocation.
So the first thing that happens is that everyone who uses NATs already has a convenient address. If my home IP address is 18.242.0.29, and my desktop behind the NAT is 192.168.0.2, then if I want a public IPv4+ address I can just use 18.242.0.29.192.168.0.2.
The next thing that happens is, if I want to reach that machine from a part of the Internet that only supports IPv4, I can tunnel IPv4+ inside IPv4. (I can even use an existing standard like RFC 1853) or something. The routers that don't need to be upgraded just see the outer header that says to send it to 18.242.0.29, and they use existing BGP or whatever and send it on its way. Once it gets to 18.242.0.29, which does support IPv4+, it figures out how to reach 18.242.0.29.192.168.0.2. Note that none of the backbone needed to be upgraded: I just need client and server support for IPv4+. End-to-end, if you look at it like an IPv4 packet, it gets routed correctly by the existing Internet.
So, there are two benefits of this strategy. First is that you use an existing naming scheme (IANA assigned IPv4 addresses) and build on top of it. The second is that you use an existing protocol and build on top of it, and only the machines that care about IPv4+ address space need to upgrade to IPv4+.
IPv6 does neither of these. Dan Bernstein condemns IPv6 much more scathingly than I can, having been part of the IPv6 discussions, but he basically agrees with me.