Also, if such a tool were possible, a tool 32to128 could be written, too.
Given that an incompatible update was necessary, there’s little difference in complexity between going for 40 bit addresses and going for 128 bit addresses.
While higher-level languages might use multi field values, perhaps even arrays of integers, most low-level code, including millions of kernel code still uses integers to store IPv4 addresses. Adding an extra octet to this would make it go bonkers.
We do have conversion from IPv4 to IPv6. All IPv4 addresses can be represented in the lower bytes of an IPv6 address.
That said, the main issue with the adoption is the inherent inertia is upgrading devices. These are physical devices and large corps and businesses don't tend to allocate sufficient budget to replace and update these things to their IT dept. unless there's a pressing business need.
Maybe a better question would be what is the most backwards compatible way to fix the IP space problem with ipv4?
It's political rather than technical: de-allocate the various Class B (/16) ranges that were distributed like candies in the past and that aren't actually used or are used only to a minuscule extent.
Routing will still be problematic though.