New languages should make sure the default random() is cryptographically secure, and hide PRNGs behind weakrandom() or repeatablerandom() or something. Safe and slow defaults are better than fast and unsafe.
Or avoid ambiguity and remove the default random(). - randomWeak() - randomSecure()
[0] In my experience, most of them -- who reads documentation these days...? Or programmers using editors like vim (no slight on vim by the way, don't shoot me!) which (generally) won't alert the programmer to the library options, unless it's been set up with a suggestion/completion/intellisense plugin?
[1] randomSecure() vs randomInsecure(), which can look similar at 3:00am on three hours sleep. Naming the functions explicitly differently makes it patently clear which function is cryptographically safe. Also helps when the interpreter/compiler won't understand the context the function is being called in, therefore can't throw warnings or errors to alert the overtired/overworked programmer that they're using insecure random number generation for crypto.
Big brain idea: Perhaps cryptographically-weak/insecure random number generators should be type incompatible by default, requiring an explicit cast to integer/float? Probably overkill, but definitely wards off mistakes and/or misuses by forcing the developer to type cast out, otherwise the compiler simply refuses, then explains why by fatal error at compile time, or by exception thrown.
But then why not make secure random number generators type incompatible by default? Because we're trying to encourage secure-by-default programming, making it slightly harder (but not onerous) to use the equivalent insecure function over secure one. Create a speed bump to prompt the programmer to think about their code, not a road block.