Since I reported this, I haven't seen any proposed solutions other other than a retry loop to ensure that the lock is guaranteed to be reacquired when the sleeping coroutine is woken.

The four possibilities of cancelling the waiting coroutine are:

1. Before wait is scheduled
   (Because the coroutine is never run, the lock is never released and a CancelledError is thrown by the runtime)
2. While waiting to be notified
   (CancelledError is thrown, but the 'finally' clause reacquires lock)
3. After wait has returned
   (This is a no-op since the wait coroutine has already completed - no CancelledError is thrown)
4. After notification, but while waiting on lock reaquisition
   (The problem discussed here)

Cancellation is quite analogous to EINTER of system calls interrupted by signals - you'll notice that the CPython runtime will retry acquiring the lock forever https://hg.python.org/cpython/file/default/Python/thread_pthread.h#l355 . This is acceptable behaviour acording the the POSIX spec http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_cond_timedwait.html , in particular:

"If a signal is delivered to a thread waiting for a condition variable, upon return from the signal handler the thread resumes waiting for the condition variable as if it was not interrupted, or it shall return zero due to spurious wakeup."

"Upon successful return, the mutex shall have been locked and shall be owned by the calling thread."

"These functions shall not return an error code of [EINTR]."

Thus, other than throwing something like a RuntimeError, there's no way to legally return from a Condition.wait without having that lock reacquired. Thus the only option is to retry if the lock reacquire is interrupted.