The `mutex-unlock!' procedure described in the SRFI accepts, as an
optional second argument, a condition variable; if specified, the
thread will atomically release the mutex and add itself to the
condition variable.  However, when the thread is awakened, it does not
automatically re-acquire the mutex.

In both the Java and POSIX thread interfaces, the operation for
waiting on a condition variable (`wait' in Java and
`pthread_cond_wait' in the POSIX thread API) automatically re-acquires
the mutex for the thread when it is awakened.

I can't see any reason this re-acquisition must necessarily be part of
the waiting operation --- clearly, the awakened thread must wait its
turn for the mutex, like everyone else.  But I think it is easier to
reason about: the invariant "I've got the mutex" holds upon entry and
exit to the waiting operation --- just not while it's waiting.

If this is a deliberate choice, it's an unusual one, and there should
be some rationale given in the SRFI.

If you decide to change the SRFI's waiting operation to more closely
resemble those provided by the other systems, then I think it should
be given its own name, instead of being attached to `mutex-unlock!'
--- it would be odd indeed for a function named `mutex-unlock!' to
return with the mutex still locked.  `condition-variable-wait!' would
be one possibility.