This kind of reasoning is backwards: you’re letting the tail wag the dog.
Consider what would happen when someone creates their own RNG—which is, after all, the whole point of exposing the protocol as we did. If that custom RNG has a long name, then it’s unwieldy to use under any circumstance. If it has a short name, then as you point out it’s going to be prone to misuse.
What you propose in this amendment would at best address this issue for the default RNG, and at the cost of an inelegant name, but the underlying problem you identify is with the design of the protocol, which goes unaddressed.
If this is truly the motivating issue for this amendment, then the most appropriate amendment that can be proposed is redesigning the protocol itself. It was mentioned earlier that a _fill(bytes:) method is currently underscored and waiting to be proposed. To prevent misuse, there is no need for the generic numeric next() and next(upperBound:) extension methods—they can be removed in favor of _fill(bytes:) and the implementations to obtain a number within a range from random bits can be moved into T.random(in:). This removal would address the issue you present in a comprehensive way rather than using unwieldy naming as a crutch here.