The spec [1] only requires that the sequence of pseudo-random numbers is repeated for a given seed within a single process ("subsequent" and "is then"). That means rand as specified is useless for reproducible sequences in fuzzing and so on. So, programs which do that already need to supply their own random number generators, and are not affected by this change.
Whereas lots of programs use rand as a source of general-purpose random numbers, but get the seeding wrong, and so suffer from various problems. This change fixes those programs.
That's an interesting way to read the specification, seems contrary to the intent and differs from how historic unix systems have implemented it. The author of the man page also disagrees with you on it being allowed by the standard ("If the standardized behavior is required srand_deterministic() can be substituted for srand()...").
Fucking things up for people who understand how PRNGs work just to fix things for people who don't seems backwards; things like this is why configure scripts take over a minute to run. I might be okay with the non-determinism in rand() if srand isn't ever called, but intentionally ignoring the stated intent of the program just pisses me off.
> non-determinism in rand() if srand isn't ever called
This is the path Go took for its math/rand library eventually: if you don't seed the RNG, it's a CSPRNG, but if you do seed it, it's deterministic.
However, there is lots of "advice" out there to seed your RNG with "random" values like the current time to make it "more secure" (and to be fair, in some cases, you may get sufficient entropy for the purpose at hand by doing this, but in most cases, you won't get enough and you'll spend it very fast). So a call to srand may indicate that you know what you're doing and want determinism and understand the consequences, but it doesn't necessarily mean that.
> seed your RNG with "random" values like the current time
Good point. srand(time(NULL)) is a common, yet nondeterministic, seed. The caller clearly doesn't expect rand() to generate a particular sequence of numbers, so srand() could check whether the given seed looks like a time_t close to the current time() and, if it does, then use a proper CSPRNG instead.
Since any good solution would start with deleting rand and srand from the C standard library entirely, but that's never going to happen, we only have not-good solutions to consider.
The spec itself contains an informative section which says:
> The following code defines a pair of functions that could be incorporated into applications wishing to ensure that the same sequence of numbers is generated across different machines.
And then gives code which does not use rand/srand. The intent of the spec is very clearly not for it to be portably reproducible.
Whereas lots of programs use rand as a source of general-purpose random numbers, but get the seeding wrong, and so suffer from various problems. This change fixes those programs.
[1] https://pubs.opengroup.org/onlinepubs/009696699/functions/ra...