I'm still at this but have been updating a stackexchange question with my observations: https://unix.stackexchange.com/q/769515/70384 (probably better than continuing to spam y'all ;))
I'll just relay the latest 2: - Running e.g. sudo zenity --calendar doesn't throw a BadAccess which again points in the direction of a file that no longer has the correct permissions, or maybe something related to MIT-SHM? It is no permissions error, or at least starting Xquartz with `--audit 4` doesn't show anything in the log. - The weirdest observation of all: there is in fact no actual delay; the time aspect was introduced by me postponing one of my usual operations: moving the initial terminal windows to the desired screen (if it's connected) and height-maximising them via the WM (xfwm4). Changing the height of 1 of these 2 windows (belonging to separate Konsole5 instances) triggers the issue and it goes away if I restore that window's initial height. If I close the window the trigger action moves to the other window. I do indeed run Qt5 applications with the xcb QPA on Mac, which I'm probably the only one to do (i.e. untested but officially not un-supported). These applications do catch a shared memory reallocation error when you change their size, but that one appears to be handled properly in Qt and doesn't cause any noticeable problems otherwise. Annoyingly I cannot find any indication what request_code 133 stands for; best guess seems to be something GLX-related. R.
