To my understanding that was the reason why SHL added the delay in xwp code. It's another story that this version of xwp source code never found the way to the public until I started uploading betas.
It sad that there seems to be no mention of what was changed, or why. Actually, that isn't entirely true, there is a list of things that changed, but the average user (including me) has no idea what it is talking about. Whether 200 ms is enough delay remains to be seen. I am not willing to change my main system, yet, but I will change other, less critical, systems (including the one where I had the problem, but it has a different hard disk now), and see what happens.
In Pete's case, he has a problem that sounds like the one that I had, and adding the delay fixed mine, so he should try it. If it fixes it, and he meets the rest of your conditions, I would suggest a longer delay in XWP. He didn't mention which version of XWP, or eWP, he is using, so the delay may work. In any case, I would suggest that the delay be left in the code, for diagnostic reasons, but it could probably be less than 4 seconds.
This all is a workaround for a problem either not understand or not solved in the right way.
There are probably 100 (or more) of those in eCS. In a lot of cases, the work around is necessary because there is no way to fix the problems properly. In other cases, nobody is interested in doing it. And in even more cases, those who might be able to fix them, insist that the problem doesn't exist. I suspect that most of the work arounds come from somebody who can sort it out, who fixed it because they had the problem. The rest of us are left hanging, and anything that somebody can figure out becomes the work around.
While I have your attention, why don't you turn off that annoying animation that is default on XWP shutdown? At least make it so that it is not the default.