Note however that when using a PRNG, you'd probably want to create your own seeded instance and use that:
// Somewhere in your code you have something like this:
var prng = MersenneTwister(seed: 1234) // Or you might leave out seed and it will choose a random one.
// And you'd use it like this:
let a = Int.random(in: 0 ... 100, using: &prng)
let b = Float.random(in: 0 ..< 1, using: &prng)
Having a public static shared instance of a [u]P[/u]RNG would be like promoting the idea of mindlessly using a shared mutable state, with all the problems that comes with that, in a case where is is essential that the user has a clear idea of how they are using the shared state of their PRNG instances. The same is not true for the current default RNG, as it has no state (it's only wrapping a function call) and it'is not seedable (the sequence of bits it generates is not determined by a given seed).
IMO, in the case of PRNGs, where the user wants repeatable results given a specific seed, the API should instead promote the idea that it is important that the user has a clear understanding of their use of various PRNG instances, as these instances will be shared mutable states (no matter if they are instances of classes or structs passed as inout). This is another possible problem of the current API, as the decision to use structs instances passed as inout (instead of class instances), might hide the reference semantics-like behavior we get (and want) by passing them as inout.