in the current proposal,
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p0952r2.html
That's not a current proposal, it was already approved by WG21 and added to the C++26 working draft in early 2024.
it is mentioned "In particular, code that depends on a specific
sequence of results from repeated invocations, or on a particular
number of calls to the URBG argument, will be broken."
This solution avoids breaking this.
I don't see how you can avoid breaking compatibility by introducing a new function. I also don't see how you can avoid breaking compatibility for *any* change to the algorithm specified for std::generate_canonical in previous standards Unless you generate exactly the same sequence of numbers, then you break compatibility with the old version. And if you don't break compatibility with the old version, then you can produce 1.0.
In particular, if you produce a completely different range of outputs, then you can't preserve compatibility with the original spec for std::generate_canonical.