Stolen wakeups are a fact of life though, even in cpython's implementation of condition variables.  And for the user of a condition variable the difference is so subtle as to not warrant special mention.

This is, btw, not just a posix thing.  It is same on windows, java, and in fact, comes from the original definition of a condition variable as part of the "monitor" pattern.  Condition variables are defined have this caveat to allow for flexibility in their implementation.
Look anywhere in the internets and you will find this, including here:
http://www.cs.berkeley.edu/~kubitron/courses/cs162/hand-outs/synch.html

The canonical and correct way to use a condition variable is to repeatedly wait() and verify that the wakeup condition holds.  The wait_for() method abstracts this into a convenient helper.  There is no need to befuddle the issue by special casing the python version as being guaranteed to not have suprious wakeups, but otherwise do have the stolen thread problem.  Quite the contrary, we should be careful to never overspecify our interfaces so that we may not change their ipmlementation details later.

A good summary of the situation and the reason for the specification can be found here:
http://stackoverflow.com/questions/8594591/why-does-pthread-cond-wait-have-spurious-wakeups

The comment I added to the documentation clarifies the reason why other examples in the docs were using while loops and teaches shows people how to use these constructs in a robust manner.  Removing it is a bad idea and I think you will find others will agree.  Take it up on python-dev if you want.

Unless you disagree, I'll add these test cases in addition to the broken one, which can then be fixed or removed later if it turns out to be problematic to other people.