Here is the essential parts of the test put together to get the same failure:
It goes all right on 10.0, but on 10.1 it causes a timeout in wait_condition.
That's because instead of the expected wait/synch/cond/sql/MDL_context::COND_wait_status we are now getting wait/synch/mutex/sql/MDL_wait::LOCK_wait_status.
For me, it starts happening on 10.1 tree with revision 3f2d9a902ec93327515ae94ae0c8c0c2c485d15f. On the previous revision f1afc003eefe0aafd3e070c7453d9e029d8445a8 there is no timeout.
I am not sure whether it's expected or not, because my further attempt to investigate got lost in git magic. If I look at the revision 3f2d9a902ec93327515ae94ae0c8c0c2c485d15f, it appears to be just a tiny change in an unrelated test case, which couldn't possibly make a difference.
But if I do a git diff between f1afc003eefe0aafd3e070c7453d9e029d8445a8 and 3f2d9a902ec93327515ae94ae0c8c0c2c485d15f, I get a huge diff (like 400K lines).
The sequence that triggers the failure is perl ./mtr --noreorder main.mdev-504 perfschema.global_read_lock