I see what you're saying, but I don't agree (respectfully)...
1) Nothing says that the number of bits that a processor can address has anything to do with the number of bits in an IP address. For example, when you get down to the nitty gritty, 64-bit processors don't even fully address a full 64-bits of memory space address. x64 architecture currently uses only 48-bits of the 64 for storing data to memory. Kernel space is from 0xFFFF8000 00000000 to 0xFFFFFFFF FFFFFFFF, and user space virtual addresses go from 0x00000000 00000000 - 0x00007FFF FFFFFFFF. Thus, I don't really see any reason why the processor bitness has anything to do with the amount of bits in an IP address. Also, any network drivers that I have ever written - I don't see where they'd care.
2) What I like about my solution is - you reserve one number - say zero, for IPv4 backward compatibility. Thus, the IPv4 address 10.136.77.139 would be the sane as the address 0.10.136.77.139. Any entity that knows that it's communicating with IPv4 only hardware would just drop the 0. If it were anything besides a 0, it'd be unroutable. Anyway, that leaves 255 usable multipliers to add on to IPv4 addresses,
I dunno - I haven't thought it out extraordinarily well, and i'm too tired to do so now... I _think_ it makes sense though, nite!.