Reading the code of unlock for the async_mutex, my understanding is that if there's a long list of awaiters currently for the mutex, the mutex's holder's call to unlock will call resume() the first awaiter, whose unlock call will call resume() of the next awaiter and so on and so on, potentially running out of stack space.
This potential situation might be avoided by use of an asynchronous unlock, by which co_await mutex.unlock() would suspend the lock holder, schedule it in some way for later resumption and make the first awaiter be resumed immediately by the symmetric return mechanism of await_suspend(...). Thus there would be chained calls to resume() consuming the stack.