Donald, your script appears to recreate the state from some hundreds of consecutive outputs of getrandbits(64).  Well, sure - but what of it?  That just requires inverting the MT's tempering permutation.  You may as well note that the state can be recreated from the output of random.getstate() - in which case, your script could be a lot shorter too ;-)

But that's not what real-life programs expose.  All the flaws in the PHP paper related to deducing PRNG state were found in real-life code using idiomatic PHP ways of spelling choice() or randrange(), with relatively few possible outputs.

Produce a program that can deduce the state, in Python 3, from - say - a million consecutive outputs of randrange(256), and _that_ would be interesting, because that would be relevant.  It's easy in Python 2.  But in Python 3, you can't tell from the outputs how many times MT was invoked under the covers (but, of course, you can from your contrived getrandbits(64) outputs - the C-level MT is called exactly twice for each of those outputs).

In any case, the vast bulk of the PHP flaws were found by out-brute-forcing dumb PRNG initialization, which requires nothing in the way of reproducing state via reverse-engineering outputs (see Figure 13).  Noting that idiomatic use of Python 3's choice() (etc) is resistant to the paper's equation-solving state-deducing approach is really just a footnote - the _point_ is that lame seeding is, all by itself, a Bad Idea.  That alone was enough to crack most of the PHP programs the paper covered.

As to the rest, there are already too many massive bug reports arguing about urandom()-in-general.  The title of _this_ bug report suggested it may be good enough to reduce the _number_ of urandom() bytes MT initialization uses.  But, so far, Victor & I appear to be the only ones who made an on-topic comment about that ;-)

What do you believe?  For example, do you believe it would remain a disaster if MT initialization wanted only 1 byte from urandom()?  Or is 0 the only value you can live with?