Again, I am not a network engineer and so I am a little of my depth. But I will respond in the hopes someone will educate me if I am wrong.

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.

The problem is packets flow both ways in a network.

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.

Yes, and all software had to be rewritten to use UTF-8. If you tried sending UTF-8 bits through an ASCII-only system, you'd display a bunch of garbage and even cause larger issues (as some bit sequences could have been interpreted as control/escape characters).

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.

Actually, IPv4 address can be mapped to the IPv6 address space and routed across an IPv6-only network; you have stateless NAT gateways at the edges. That allows network operators to manage a single-stack network while still giving users an IPv4 network. 464XLAT adds one more component to the picture, which is a stateful NAT gateway that allows a network operator to provide limited IPv4 service without giving each user a public IPv4 address. For reference:

https://en.wikipedia.org/wiki/IPv4_mapped_address#IPv4-mappe...