> So it seems like I must ship a specific determinized library with my
tests.

That is probably the best solution. You wouldn't be able to act
`random-port-state` on it, but in this situation you could probably hack
around it (make the random port a global for example). For a more
general scenario you'd probably need a more expressive custom port
system in an implementation.

 > Alternatively, we could choose a specific determinized library and
ship it as part of SRFI 271, but then if it is cracked we'd be in trouble.

I don't think its a big issue if the generator is cracked (since you
know what the seed is, it is not a requirement that it is
cryptographic/unguessable). The bigger issue in my mind is that there
are a lot of different ways to implement an algorithm. For instance, an
xoshiro256++ implementation can skip N number of start bytes to get to
more random data. Another example is ChaCha20, where an implementation can

1) Implement it using a counter, no forward security (this has the
advantage that the stream is seekable)
2) Implement it by reseeding each block
3) Implement a fusion of the above for a balance of speed and security

-- Peter McGoron