It is far away from transparent. Devices behind the router can't know that a change in Public IP happened and won't reconnect active connections.
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.
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.
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.