This is why I'm unwilling to accept this change in 3.5.2.  This sort of "we think it's right" behavior is only appropriate in a point release like 3.6.

I think odds are better than even that I'm going to get an os.getrandom(n, block=True) call in 3.5.2.  It solves problems, and its behavior is predictable on a platform-by-platform basis.  It also won't change the behavior of any reasonable existing code.  (Yes, someone could say "if hasattr(os, 'getrandom'): detonate_the_device()" but that's unreasonable.)

If os.getrandom(n, block=True) goes in 3.5 and 3.6, this makes adding a block parameter to os.urandom() less interesting.

Also I disagree with adding the block parameter to os.urandom() in the first place.  os.urandom() should behave like the /dev/urandom device on the local OS.  Whether or not /dev/urandom blocks is system-dependent behavior. On Linux, it's guaranteed to never block; on FreeBSD it is permitted to block under certain conditions.  At the point that you say "but on Linux we're implementing os.urandom() using the getrandom() system call, which has the ability to block if you want", you are straying quite far from the behavior of os.urandom().

Functions in the os module are intended to provide a thin shell around the equivalent local OS function, and should behave predictably like that local function.  os.stat() should behave like the local stat(); os.utime() should behave like the local utime(); and os.urandom() should behave like the local /dev/urandom.  It's okay to add functionality for free, but it's not okay to degrade behavior (like "it might block forever").

Since the behavior of /dev/urandom already varies so widely between different platforms, I think it adds unhelpful complexity and confusion to add the block= parameter.  I think we're much better off with a new function providing the local system call: os.getrandom(), if available, and perhaps os.getentropy(), if available.  Then we preserve the "behaves predictably like the local system call" approach of the os module.