I would tend to split these blocks out into seperate subroutines...

I'll do that.

... on OpenBSD, the two devices are known as /dev/srandom and /dev/random.... FreeBSD also names them slightly differently.

I'll investigate this.

... opens up the possibility that client code can add their own seeding routine...

Good idea. I'll add that in.

And if the seeds() routine is called without any parameters, you should return the current seed array.

I did make the seed array visible, but this is a better idea.

... so that people have the chance of serialising the state of the generator, in case they wish to "pick up where they left off" in a subsequent program invocation.

The seed and the PRNG's state are different entities. However, I get the idea and I'll add a state() function for this purpose.

... you ought to add some statistical tests in your test suite...

The statistical analysis of the Mersenne Twister is available on the web. The t/mersenne.t test checks the PRGN's workings by checking its output for a known seed. If that test file passes, then the PRGN is working properly. That should cover things.

... get a random number back from 0 .. MAXINT.... you can save a few cycles by avoiding the initial reciprocal division.... Being able to get at the raw U32 value would be nice.

The rand32 function does return 0 .. 2^32-1 (i.e., the raw U32 value). I put it in specifically to avoid the floating point math when it's not needed.

Thanks for the great feedback.