> No facility for a user-provided seed, preventing programs from getting reproducible results
> Periodically “stirs” the generator using kernel-provided entropy; this code must be removed if reproducible results desired (in testing its speed, I deleted this code)
seem like exactly the kinds of foot guns you really want removed from an RNG you're using for real live code.
Sometimes you want well-mixed numbers, but in a sequence that you can rerun. If you are simulating a process or testing games, having a fully deterministic setup if you know a seed is a great help to reproduce unusual behavior sighted.
Reproducibility and seed-ability isn't a footgun unless it's easy to do wrong accidentally, or hard to do right accidentally.
The former really isn't a problem except for really poor APIs, and the later isn't made worse by it... although the PCG random author does like to make a point of just how bad it is in C++ (see [1]).
Produce a set of random numbers once and store them as part of the test set. That way your test is independent of the black box which is your RNG. Or make your own simple RNG - in these cases you are looking for "arbitrary, definitely not just sequential" rather than cryptographically random (or, indeed, truly random at all).
If you rely on the order of the output, for reliably consistent test cases in this instance, avoid using black-box RNGs which could change implementation under your nose without much or any warning.
Cryptographically random isn't the aim here - pseudorandom is.
A seedable black-box RNG that guarantees what seed corresponds to what stream is way simpler to use than a list of random numbers, IMHO. It's the difference between copying one number and copying a million.
> A seedable black-box RNG that guarantees what seed corresponds
If you can control when the blackbox gets updated, or the blackbox carries a guarantee of stable output for any given seed over the while time of its existence, yes. But if you are using OS provided RNGs, as a for instance, their behaviour is not defined (well they are, but those definitions are not set in stone) and may change as kernel updates happen.
That is why I suggest "making your own simple PRNG". This could be as simple as picking a known documented algorithm as implemented by a particular library and using that in your test cases - it doesn't need to be as much as writing your own function even.
> No facility for a user-provided seed, preventing programs from getting reproducible results
> Periodically “stirs” the generator using kernel-provided entropy; this code must be removed if reproducible results desired (in testing its speed, I deleted this code)
seem like exactly the kinds of foot guns you really want removed from an RNG you're using for real live code.