This was introduced with a mismatch between d3d8 and d3d9 in f4d520d6 https://gitlab.winehq.org/wine/wine/-/commit/f4d520d6e2e3d486fa691eefee07fecc0ba6fe6c. Matching the two of them seems fine regardless, but I also don't understand why the minimize/restore is there in the first place. Stefan, I don't suppose you can elucidate?
It's a long time since I wrote those tests, so my memory might be off...
I vaguely remember that minimizing and restoring a window allowed foreground stealing on Windows. Afaiu on an older testbot version, those tests ran from a shell that wasn't the foreground window. A pile of minimize and restore sequences got it working.
Also d3d8 and d3d9 behaved (behaved?) differently when your process wasn't foreground. Native d3d9 magically allowed us to call SetForegroundWindow even though our parent wasn't the foreground process. My guess is it called AllowSetForegroundWindow. I once experimented with this and tried to get the tests to pass with builtin d3d9 (+wined3d) on windows, but wasn't entirely successful. So d3d8 vs d3d9 differences aren't entirely unexplainable.
Finally I had to pacify Alexandre's focus-follows-mouse fvwm2. It is a bit hard to write focus tests when a mouse pointer, left behind at a random location, will override the tests's choice of foreground window. fvwm2 in click-to-focus was about the sanest WM I tested this on. focus-follows-mouse is hell. Afair I fixed this with a mix of testing if my SetForegroundWindow actually did what I wanted it to do and some more redundant minimize-restore in the hope of fighting fvwm2 to a draw.