So you haven't solved the incompatibility at all. Your v8 requires the client, server and everything between them to support v8 or it has to fall back to using v4, just like v6 does.
> There are two groups that should update to v8 in order to be fully functional: users' OS net stack and ISPs' infra.
A lot of software hardcodes AF_INET or sockaddr_in, and so can only handle 32-bit addresses. Also, there's the end-user's border router, and any internal routers on the client or server side, and the LANs on the client and server sides. There are databases, protocols and data structures that store IP addresses. Any attempt to use v8 with any of these will break them even if half of the v8 address is set to zeros, because they can't handle the 64 bits of a v8 address. They'll either reject the address or it'll corrupt the next 32 bits of memory. A seamless update to the OS net stack and ISP infra isn't sufficient to make them work with v8, because they'll still be limited to 32 bits.
I understand that your core idea is to say that a subset of the v8 address space maps directly to the v4 address space, so that you can convert that subset to v4 to work with the above things. This idea itself isn't bad; it's a perfectly sensible backwards compatibility mechanism that's used by v6 too. You're correct that it allows just that subset to be passed to an application over an AF_INET socket, used to send/receive v4 packets to the corresponding v4 address and so on. This approach is seamless if you stick to exposing the addresses as v4 addresses rather than as v8, because then they could be handled the same way v4 addresses are.
The problem is, you can only make it seamless by hiding the full v8 addresses and pretending they're v4, which can only be done for a small fraction of v8 addresses. What about the rest of them? You haven't actually extended v4's address space past 32 bits, so if you want to use v8's extra addresses you'll have to expose the full v8 addresses as v8 addresses, which is no longer seamless because that's a whole new stack the user and their software has to deal with.
If it was possible to seamlessly switch to bigger addresses, there would be no reason to restrict yourself to the subset of v8 addresses that end in :0:0:0:0 in the first place. You're doing that because using bigger addresses isn't seamless, which is an acknowledgement that a seamless upgrade to bigger addresses isn't possible. It would be if they were the same size, but then you've failed your goal of extending the address space.
So no, you can't claim this upgrade would be seamless unless you can remove the part that's only in there because it's not.
> If a single node is still at v4, all the communication continues v4-like (the v8 nodes send 0 at the ls32b).
If a single node is still at v4, that node will drop your v8 packets even if you set the ls32b to 0, because it doesn't understand the v8 packet format in the first place. This node will prevent you from switching to v8 even if you stick with the limited v4-compatible subset of v8 addresses.
> it will be SEAMLESS for the user, without the awful v6 UX that we have now
That "awful v6 UX" is the same UX you'd get with v8 if you tried to use the expanded address space. Or, if you limited yourself to just the v4-mapped subset of v6 then it would be just as seamless as v8 is. This should be obvious, because you already lived through OSs adding support for v6 in their net stacks and it was seamless so long as you stuck to the part of v6 which maps directly to v4. Which is what you were asking for, wasn't it?