To those who say this is impossible, not quite. Any IPV8-capable system would consider missing sections being high-order octets and their value to be 0. Thus, a request by an IPV4 system for 184.108.40.206 would be resolved by the IPV8 network to the same address 0...220.127.116.11. Certain networks that work only on version 4 would have problems. Any change does that. However, you could get one system functioning on IPV8 without breaking the others, as an IPV8 router would not break an IPV4 client. More specifically, all the original IPV4 tactics would hold--0...127.0.0.1 is still localhost, 0...10.0.0.0 is still private address space, etc. IPV6 does not do this, either on the theory that the features aren't needed or simply because they changed all the numbers. That results in the IPV6 system functioning independently from IPV4, but not functioning at all for backward compatibility. Perhaps it's wishful thinking, but perhaps if systems could be upgraded in place using a model as described, it would have been easier to transition.
I'm sure there are corner cases in code that would not allow any of this automatic code to function, although I'm not sure which parts of the code would break, but that is the case for any change, and people make plenty. People upgrade operating systems with the knowledge that code may need updating afterwards, but that most of it will still work. People have found ways to upgrade hardware without bringing down the systems running on it. By designing a system that provides the new functionality with a layer designed to allow most, if not all, legacy code to work, the barriers to construction of the new system are significantly lowered.