To be clear, I have no qualms about making a namespace like Random which would house properties like default. What I do not like is the default random number generator object being named Random itself. It's just the wrong name. At the very least, it should be called RandomGenerator to actually describe what the object is. Random isn't descriptive of anything, it's at best poor shorthand. It refers to the domain of randomness rather than what this particular type is.
Let's imagine we introduced a Random namespace or submodule (something that was never formally proposed or agreed on in SE-202) but clearly has many people desiring it. We would still need a name for the stdlib generator. You could conceivably imagine:
enum Random { // namespace
var `default`: DefaultRandomNumberGenerator { ... }
}
I personally would love to hang a default instance accessor off of the RandomNumberGenerator protocol type itself, so you could declare something like func random(using generator: RandomNumberGenerator = .default). Again, this requires a fully-formed name for the type vended.
extension RandomNumberGenerator.Type { // this is obviously hypothetical syntax of a feature that is nowhere close to implementation currently
static var `default`: DefaultRandomNumberGenerator { ... }
}
The mere fact that people keep proposing the idea of Random as a 'namespace' is indicative that Random is not the correct name for a RNG source struct. If this proposal was already out in the wild, part of the public Swift language, I would agree it is not so harmful to be worthy of renaming and code churn. But pointedly, it is not yet finalized API. There are no source compatibility concerns at this stage.