The answer comes from the suggested design: you update your DNS right after you run the new stack, irrespective of what others (ISPs and users) do. The records will initially still function as v4 (discard the lb32b). Only when all others switch, they will enable their full length.
Obviously there should be simulations and refining to avoid edge cases and conflicts. I will not design the full spec.
So anybody without the new stack loses access to your site, because they're querying for the A record that you removed. How is this "a gradual migration" or "expanding the address space without inventing a new stack"?
Nobody will want to switch to the new stack if it means instantly losing clients that don't have the new stack yet, so the only way to switch would be to coordinate everybody on the planet to switch simultaneously. This is as far away from a gradual deployment as you can get. A flag day for the Internet isn't viable, no matter how much you shout it.
These are not edge case questions we're asking here. They're fundamental questions about how to expand the v4 address size without ultimately doing the same things v6 had to do. You don't need to design the full spec, but you don't get to argue we should replace v6 if the best alternative approach you can come up with works the same way v6 does and has the same limitations v6 does.
Obviously there should be simulations and refining to avoid edge cases and conflicts. I will not design the full spec.