Since the tests for this ticket were integrated into the Tk test suite,
I didn't have a close look to them. (That's merely because my drive to do so
is inversely proportional to my confidence that you did this accurately,
François.) Well, I did that now, and everything looks fine to me, except for the
following two aspects where I have a small doubt/question:

A. Regarding this line:


    In my original test script the code reads:

        tkwait visibility .
        update; # service remaining screen drawing events (e.g. <Expose>)

    Now it is:

        _pause 200; # service remaining screen drawing events (e.g. <Expose>)

    a. Was the removal of the call to "tkwait visibility" on purpose? It makes that
       we can't be sure that the window is visible, e.g. if the end user's system
       is very busy processing other stuff during the 200 ms that the Tk process
       is waiting). This makes me uncomfortable.
    b. If the removal of the call to "tkwait visibility" was on purpose, then
       the comment is somewhat misleading, especially the word "remaining".
       What's happening during the [_pause 200] is much more than just the
       servicing of "remaining" drawing events. A better comment would be:

          _pause 200; # let the drawing of the window to the screen occur to its completion

       (or something equivalent).

B. Regarding the 200 ms that _pause is waiting:
   It didn't go unnoticed that 200 ms is less than the current value for MOUSE_TIMER_INTERVAL
   (250 ms). The choice makes that there is no time for the sequence MouseTimerProc() -> Tk_PointerEvent()
   to be run twice. (This is on MS Windows, I don't know if this also holds for macOS/aqua).

   Was this consideration indeed the reason for choosing 200 ms? If so, wouldn't it wise to
   add this as an explanation somewhere?