I have been looking for a more permanent solution to that proposed in PR-23156. The most obvious solution is probably what I suggested in msg380371 as I don't believe the calls to `wait_visibility` are required (though, I don't really know enough to say for certain so am wary of making the tests unstable in a different way).

Another initial idea I had would be to mess around with threads and interrupt the main thread (which would be caught and ignored) if `wait_visibility` took too long.

It would be better, though, if we could actively predict a `wait_visibility` failure. I looked again at the Tcler's wiki (https://wiki.tcl-lang.org/page/tkwait+visibility) and noticed the hidden discussion titled "Windows bug or whatever - looking for help". In that discussion is a description of exactly the issue we are facing:
"Under strange totally unrelated circumstances [...] tkwait waits forever."

There, the OP includes a version which only calls `wait_visibility` if `winfo_ismapped` is 1, saying:
"The "winfo ismapped" is only 0 if the tkwait will stall"

In some initial testing (see attached demo script - uncomment the update call for `wait_visibility` to stall) I found the opposite to be true (`wait_visibility` fails when the widget *is already* mapped - I think this is because `wait_visibility` is waiting for VisibilityNotify but this was already issued when the widget was being mapped). Another proposed solution on the wiki is to avoid `wait_visibility` completely and instead use a combination of various calls including `tkraise` & `focus_force` (ideas/opinions?)

Note: I included both `winfo_ismapped` and `winfo_viewable` in the test script to try and find a case where the value of one is not the same as the other but I believe `winfo_ismapped` is the one we would want to use.