I think we're talking about a different issue here. MultiWAN does break consumers which do not support reconnecting from a different source IP. But the issue is the same with IPV6, if the prefix changes, the client has to reconnect anyway.
Also, I'm personally not aware of any reliable way of invalidating IPV6 prefixes except waiting for the timeout. (And if it's republishing a RA, devices don't have to listen to it, and the packet might even be lost with an unreliable wifi for example). If I'm wrong here, I'd love to know about it.
See also "Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events":
In scenarios where network configuration information related to IPv6
prefixes becomes invalid without any explicit and reliable signaling
of that condition (such as when a Customer Edge router crashes and
reboots without knowledge of the previously employed prefixes), hosts
on the local network may continue using stale prefixes for an
unacceptably long time (on the order of several days), thus resulting
in connectivity problems. This document describes this issue and
discusses operational workarounds that may help to improve network
robustness. Additionally, it highlights areas where further work may
be needed.
Also, I'm personally not aware of any reliable way of invalidating IPV6 prefixes except waiting for the timeout. (And if it's republishing a RA, devices don't have to listen to it, and the packet might even be lost with an unreliable wifi for example). If I'm wrong here, I'd love to know about it.