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.
Short lifetime RAs for all of the address spaces are meant to cover this.
Re:Router Security
by throw0101a on Saturday July 30, 2022 @09:36AM
(#32286711)
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.
One example is Apple's APNS and Android's GCM. In IPv4 multiwan network, after the change they won't receive notifications at all for up to 30 minutes. In IPv6, the router can invalidate the old prefix, and publish a new one immediately.