Hi Pierre,
Thanks for checking with a GNOME and KDE environment and sorry that it took so long to answer your question.
I just updated our server and ThinLinc client to 4.20.0 now (also in the hope that the issue might fade away) and the issue unfortunately still exists.
I debugged this a bit further now and could pinpoint it to our Lubuntu (LxQt/OpenBox) environment. So we are not using GNOME/KDE here, but have a Lubuntu-based environment for our users simply to keep things lightweight. And if I connect to the same server, but select a different window manager/environment then the issue vanishes. In fact, it seems to indeed be enough to change the window manager to xfwm4 and not use the default openbox window manager with LxQt. Then the issue is also gone and the windows that are on a second screen when re-connecting to a ThinLinc session are NOT moved to the primary screen (or towards it) anymore. So it seems the issue with ThinLinc client 4.19.0 and newer only appears if an openbox window-manager environment is used. I could also verify the same with a different Lubuntu system where a thinlinc server is running. As soon as I switch from openbox to e.g. xfwm4 the issue disappears.
So could you perhaps try to reproduce the issue with Lubuntu (LxQt/OpenBox)? To me it seems to be related to the point that somehow OpenBox things upon re-connection that it has to re-locate windows on the secondary display (probably because the full monitor setup is not yet fixed upon re-connection) to the primary (leftmost) display. In fact, looking very closely one can see that upon re-connection to the ThinLinc server there seems to be a somewhat more severe screen flickering at the very start of the re-connection when using 4.19.0 compared to 4.18.0 which looks like the connection first comes up with only one display and then a few milliseconds later the second display appears, which in fact could trigger the OpenBox window-manager to run the window re-location procedure. And other window managers do not seem to be affected here or handle this re-location a bit differently, e.g. later when both monitors are correctly assigned.
Would be great if you and your ThinLinc crew could try to reproduce this issue once more as I am sure this must be related to some change in the ThinLinc client from version 4.18.0 to 4.19.0 which might handle full-screen/multi-monitor setups a slightly bit differently, which triggers this OpenBox-related issue.