MySQL's bug #11745929 fix contains lock_rec_has_expl() function optimization:

commit 7037a0bdc83196755a3bf3e935cfb3c0127715d5

Author: Jakub Łopuszański <jakub.lopuszanski@oracle.com>

Date:   Mon Jan 31 17:36:48 2022 +0100

    Bug #11745929 CHANGE LOCK PRIORITY SO THAT THE TRANSACTION HOLDING S-LOCK GETS X-LOCK F

...

`lock_rec_has_expl` checked if a transaction already had a GRANTED equal or stronger lock then the currently requested, but it didn't use the fact that the queue is ordered so that all GRANTED locks are before all WAITING locks. The new implementation stops as soon as it finds a WAITING lock

...

In MySQL lock queue is split into two parts: GRANTED and WAITING locks. WAITING locks are always pushed to the tail, and GRANTED locks are always pushed to the head, even when WAITING lock is granted. So it's enough to stop when the first WAITING lock is found in lock_rec_has_expl().

In MariaDB there is no such division. But if we take the certain transaction, all its GRANTED locks well be before its WAITING lock in the queue. So for MariaDB we can stop when waiting lock of the checked transaction is reached.