That's both very interesting and important to know, since it probably means that the answer to the question in the title of my other thread:
When is the implementation of SE-0202: Random Unification allowed to change?
is: Whenever it's needed.
Meaning for example that if I implement my own pseudo random number generator, conforming it to the RandomNumberGenerator protocol, then I …
While I do think that the Random API should be able to change and improve whenever it's needed, I also think that the documentation should at least mention/warn about this, especially since the whole point of using PRNGs (rather than the default truly random / unseedable system RNG) is about reproducibility and/or efficiency.
More generally, but still in the context of PRNGs, reproducibility and efficiency, I think it's problematic that the design of the Random API mandates certain "one-single-true-ways" of mapping the (pseudo or truly) random UInt64 values into eg Float values, rather than having them as customization points.
Also, the Random API has been designed in a way that spreads these non-customizable methods all over the standard library, making them hard to "avoid" and easy to confuse with potentially needed alternatives.
These concerns are rooted in a real world example, one of our current projects, a game with procedurally generated content/levels, so stuff can be described and reproduced solely by a seed, and efficiency and reproducibility is crucial). Our conclusion is that we have to use our own alternative little pseudo random lib on the side, making sure to design it in a way that avoids any potential confusion with the Random API (which is all over the std lib).
IMO it would have been better to let the Random API mature as a stand alone lib. It would have been small enough to be easily tried out and evaluated by anyone, simply adding it to projects as source (and not as a module, to avoid the issue of missing cross-module optimization).