[Bug 55778] New: user32:win - CreateWindowEx() sometimes unexpectedly succeeds on on Windows 7

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=55778

Bug ID: 55778
           Summary: user32:win - CreateWindowEx() sometimes unexpectedly
                    succeeds on on Windows 7
           Product: Wine
           Version: unspecified
          Hardware: x86-64
                OS: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: user32
          Assignee: [e-mail]
          Reporter: [e-mail]

user32:win - CreateWindowEx() sometimes unexpectedly succeeds on on Windows 7:

win.c:6748: Test failed: CreateWindowEx should fail
win.c:6749: Test failed: IsMenu set error 0
[...]
win.c:11799: Test failed: 001B01FA: expected prev 00000000, got 00A500A2
[...and always 20 more 'expected prev' failures...]

See https://test.winehq.org/data/patterns.html#user32:win

The first known instance happened on 2023-06-15 (none in the previous 4 months)
and there have been a bit over 1 instance per month since. This test has been
there for years so something else must have changed to cause these failures.
* 2023-06-15 win7_newtb-w7u-2qxl
* 2023-07-19 win7_newtb-w7u-2qxl
* 2023-08-30 win7_newtb-w7u-2qxl
* 2023-08-31 win7_newtb-w7u-2qxl
* 2023-09-20 win7_newtb-w7u-2qxl
* 2023-10-09 win7_newtb-w7u-2qxl

test_topmost()'s "expected prev" failures always follow the initial the initial
CreateWindowEx failure and never happen without it. So they can be considered
to be collateral damage.

Then the question is: why does CreateWindowEx() unexpectedly succeeds?
The documentation says hMenu can be a 'child-window identifier, an integer
value'. Could it be that sometimes the desktop window has a child window with
identifier 1?

(HMENU)1 is used two more times. Why don't we get failures there too?

Should the test use a more unlikely value like 0xdeadbeef?