The following is from years of memory, so it might not be accurate. It's been more than a decade since I added the tests. TL;DR: Remove or if(0) the test.
The reason why this test tests the *absence* of WM_WINDOWPOSCHANGING and related messages here is that some games call Device::Reset from their WM_WINDOWPOSCHANGED handler. Due to d3d9's filtering of d3d9-caused messages, this does not lead to an endless recursion. The concept was introduced in c24e48d937cfd0000a22af555a920ea7fab71d7b for a game that crashed during device creation because it reset the not yet created device on the fullscreen mode switch + window resize. This particular line is checking that the same applies on focus loss / regain. I don't know if there's any application that would otherwise run into an endless loop during focus loss. I couldn't find out which game was affected because the commit doesn't say, no bug report is
I think (but again, memory from my last time I tried to make those tests more reliable) the test fails because there are other reasons why WM_WINDOWPOSCHANGING can be sent, and because they are outside of d3d9's (or wined3d's) window operations, they are not filtered and the test can't tell them apart. A lot of the flush_events() calls are there to prevent external events from interfering, but it isn't wholly reliable everywhere. There is no way to ask d3d9 if device creation/focus loss/focus regain/device reset/device destruction is ongoing from inside our message handler and a "I am calling d3d now" flag in the test is racy vs external events.
Another aspect specific to WM_WINDOWPOSCHANGED is that some window operations are no-ops and only send a WM_WINDOWPOSCHANGING, but not a WM_WINDOWPOSCHANGED message. However, what is a no-op and what is not depends on the window manager and I remember that kwin - which is otherwise very well behaved - decided to move or resize windows in some situations and caused a WM_WINDOWPOSCHANGED message to be sent anyhow.