Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

If the simple overloads were warranted for RandomNumberGenerator, they're just as applicable to Random.

I want to push back a little against this statement, because I don't think it's universally true. A byte stream retrieved from RandomNumberGenerator is likely to be used as key material, or a nonce, etc. And a hex string is just a transmittable text representation of that data. It's essentially a helper over the existing RandomNumberGenerator.GetBytes method.

The Random.NextBytes method, on the other hand, has more restricted legitimate use cases. While getting one-off numbers (Random.Next) finds use in mechanisms like backoff and throttling, sequences of data (like via NextBytes) are much more likely to be transmitted or persisted. This merits a deeper investigation on where the data eventually flows to. And it's why callers of APIs like Random.NextBytes are occasionally audited by internal security teams -- because they're more likely to indicate misuse.

This isn't to say the API should be rejected. There are valid use cases, such as generating filenames in a trusted destination directory (emphasis on trusted since you don't want to implicitly rely on unpredictability). I'm just pushing back on the "it exists <here>, therefore it should exist <there>" justification as quoted above and I personally would like to see a stronger argument.

There are plenty of uses, as you call out. Right now we make it harder to use the cheaper option, either pushing users to the cryptographically-secure api for convenience when it's not technically warranted, or making them write more complicated code. If there were zero uses, sure, but that's not the case, and my comment is in the context of there being valid uses. For both, GetHexString is a convenience method.

Video

• When we added these to the CSPRNG we believed no one would need them on System.Random. New data has proven otherwise.
• "Should these be virtual?" GetItems and Shuffle aren't. These are matching that. If we change any to virtual we should change all to virtual.
• Should we add GetString that writes to a span? No, it's redundant with GetItems.

namespace System;

public partial class Random
{
    // same signatures as on RandomNumberGenerator, but instance instead of static
    public string GetString(ReadOnlySpan<char> choices, int length);
    public string GetHexString(int stringLength, bool lowercase = false);
    public void   GetHexString(Span<char> destination, bool lowercase = false);
}