The current proposal establishes a pattern of adding random-related convenience functions as extensions to instances or types. So Random.default.fillBuffer() would be expressed as something like Buffer.randomBytes(byteCount:using:) at the type level or buffer.randomizeBytes(using:) on an instance. The using argument is optional, defaulting to the stdlib RNG's source. Why would this need to be inverted?
The idea that Random can act as a namespace is neat, but this intent is not described in the original proposal at all. If namespacing these types is worthwhile, then even so I would vote for some syntactic amendments. Random should be a enum (or a formal namespace declaration when we have one) and offer a static method like default which vends a DefaultRandomNumberGenerator. It doesn't really make sense to have a Random struct type also be the namespace.
If brevity is deemed a concern by many, DefaultRNG is still vastly superior to Random in my opinion. The abbreviation refers back to the name of the parent protocol, so I think the logical hierarchy is generally maintained. Still, I laid out my reasoning as to why I think character count is not of primary importance here.
(FWIW the idea that the standard library should host namespaces at all, with the expectation for others to extend it, is something that deserves discussion and not taken at face value. This isn't a common stdlib pattern today. When I read the original proposal, I was thinking that Xorshift128RNG (eg) and DefaultRandomNumberGenerator would simply sit alongside each other as top-level types.)