The problems this caused/s seems to have been an unintended / unforeseen consequence that was more exposed as people gained experience. There's a draft being worked on to officially change the priority:
> The behavior of ULA addressing as defined by [RFC6724] is preferred below legacy IPv4 addressing, thus rendering ULA IPv6 deployment functionally unusable in IPv4 / IPv6 dual-stacked environments. The lack of a consistent and supportable way to manipulate this behavior, across all platforms and at scale is counter to the operational behavior of GUA IPv6 addressing on nearly all modern operating systems that leverage a preference model based on [RFC6724].
Leaving aside that the draft is badly worded (there are long descriptions of the problem, but no short paragraph saying what must be changed), the long time until this is deployed if ever, the new order will still leave ULA below IPv6 global addresses - which means it doesn't solve stock_toaster's problem at all.
The problems this caused/s seems to have been an unintended / unforeseen consequence that was more exposed as people gained experience. There's a draft being worked on to officially change the priority:
> The behavior of ULA addressing as defined by [RFC6724] is preferred below legacy IPv4 addressing, thus rendering ULA IPv6 deployment functionally unusable in IPv4 / IPv6 dual-stacked environments. The lack of a consistent and supportable way to manipulate this behavior, across all platforms and at scale is counter to the operational behavior of GUA IPv6 addressing on nearly all modern operating systems that leverage a preference model based on [RFC6724].
* https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ula