I've seen this objection, and I do not see how it could be otherwise.
If all the code out there was for 32-bit-only addresses (of IPv4), then expanding the addresses space to something >32 bits would entailed updating every single IP-capable code. Which is exactly that needed to be done for IPv6: every device needed to have code updated (and this included 'hardware code' of things like ASICs).
While UTF-8 is backwards compatible with ASCII, it did of course require programmers to add support for it just like you are suggesting any successor to IPV4 would. But once that support was added, ASCII could be treated as part of UTF-8 standard.
From what I understand, this is not the case with IPV6 and IPV4. The former requires its own software stack and the IPV6 standard was written (from what I have read) without any attempt to make it possible for IPV4 and IPV6 addresses to coexist in the same software stack easily.
It's not like an actual pipe where one end doesn't care where the other end is. The recipient of a packet has to know where to send the reply.
So while a host with a larger address could easily talk to a legacy host with an older, smaller address, the legacy host couldn't reply because it wouldn't know how to address it.
So, just like expanding address space (IP: 32-bit to 128-bit; ASCII: 8-bit/1-byte to multi-byte), you had to rewrite all the software to handle things.
https://en.wikipedia.org/wiki/IPv4_mapped_address#IPv4-mappe...
ipv6 is not backwards compatible with ipv4.
Consequently adding support for ipv6 requires a dual stack solution (since supporting ipv4 is a must).
An alternative solution to the problem of the limited number of ipv4 addresses has been reliance on NATs. This is much simpler than supporting ipv6 and is already widely adopted everywhere, and so that's what people are choosing to do.
The obvious conclusion (from a casual observer like myself): the successor to ipv4 has to be backwards compatible with it, similar to how UTF-8 is backwards compatible with ASCII.
EDIT: I should note that I am not a network engineer, so if anything I have written is incorrect, I hope someone corrects me.