Since 10.6, the group commit logic in Innodb allows asynchronous waiters. One aspect of group commit lock with that got a little more complicated - passing a group commit "torch" , i.e electing new group commit lead when current one is releasing the lock.

In 10.5, group_commit_lock::release would wake up one more waiter than needed, and this woken thread becomes the new group commit lead.

in 10.6, group commit lock keeps 1 synchronous waiter (even if the caller was using callback, and intended async execution), as a "standby" , so that waiter can pick the "torch". This is not usually , but not always enough, and there can be pending callbacks in group commit lock, while there is no new lead.
(There is no huge tragedy still, in worst case those callbacks are released by periodic redo log background flushing)

To avoid this situation, group_commit_lock::release could tell the caller that some pending work is still there, if there is no new lead. And the caller (log_write_up_to), would redo write/flush one more time.