I believe the cause is somewhere along these lines:

The relevant code in 2.3 is here:

There's a fair bit of difference between them. Do you think you could try playing with the WS_* bitfields and see if it helps? There's a bunch of different cases to be handled here with regards to focus handling, and evidently I missed some. Note that some of the WS_* values include the other, like WS_OVERLAPPEDWINDOW.

Here is the fairly confusing Microsoft doc for window styles.

I managed to arrive at the correct behaviour by applying the following:

diff --git a/src/platform/guiwin.cpp b/src/platform/guiwin.cpp
index 73da2da..ec6bfca 100644
--- a/src/platform/guiwin.cpp
+++ b/src/platform/guiwin.cpp
@@ -545,7 +545,7 @@ public:
                 break;

             case Window::Kind::TOOL:
-                style |= WS_POPUPWINDOW|WS_CAPTION;
+                style |= (/*WS_POPUP | */WS_BORDER | WS_SYSMENU)|WS_CAPTION|WS_CHILD;
                 break;
         }
         sscheck(hWindow = CreateWindowExW(0, L"SolveSpace", L"", style,

However, the window now looks like absolute garbage pretty bad (and, perhaps more importantly, appears permanently disabled):

Unfortunately, I haven't managed to make it look platable nor as-was in 2.3 (not for lack of slamming my head against a proverbial wall) with any combination of more or less sensible options.

Also, a few questions that popped up while I was making this:

1. Do you consider warnings bugs? Because this file has two, so dunno what I should do about them, and
2. Scrolling in the Property Browser selects the face that's below it (didn't happen in 2.3), is this intended?

However, the window now looks like absolute garbage pretty bad

Have you tried this? I think the property browser isn't intended to have a sysmenu, and that might make it look better:

style |= WS_BORDER|WS_CAPTION|WS_CHILD;

and, perhaps more importantly, appears permanently disabled

That's actually intended, or at least that was the 2.x behavior, IIRC. This should have the effect of forwarding key bindings to the parent window.

Can you try disabling the following code and seeing if key bindings (e.g. d) are still forwarded?

Scrolling in the Property Browser selects the face that's below it (didn't happen in 2.3), is this intended?

Here is the part of the code that deals with scroll events:

I'm not entirely sure from your description what went wrong here.

Do you consider warnings bugs? Because this file has two, so dunno what I should do about them

Depends. Some warnings are useful, some are not, and compilers constantly add new warnings. You could post them here if you wanted.

The WS_BORDER|WS_CAPTION|WS_CHILD combo does look marginally better:

In both 2.3 as well as unpatched master, the Property Browser window can be focused, which provides a visual indicator, that it's interactable:

Commenting out the else block has no effect on d being forwarded in both WS_POPUPWINDOW|WS_CAPTION and WS_BORDER|WS_CAPTION|WS_CHILD window styles.

Another thing I saw in taking those screenshots is that in the WS_CHILD-containing variant the Property Browser window is constrained to the sketch window and cannot extend beyond it:

Here's a video illustrating the issue: the scrolling code works fine, but the as the mouse is over the Property Browser window and scrolling, if there's any selectable face in the sketch window at the mouse's position, it will be highlighted, until the mouse is moved.

[1/2] Building CXX object src/CMakeFiles/solvespace.dir/platform/guiwin.cpp.obj
../src/platform/guiwin.cpp: In function 'UINT SolveSpace::Platform::ssGetDpiForWindow(HWND)':
../src/platform/guiwin.cpp:70:78: warning: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'SolveSpace::Platform::LPFNGETDPIFORWINDOW' {aka 'unsigned int (*)(HWND__*)'} [-Wcast-function-type]
             GetProcAddress(GetModuleHandleW(L"user32.dll"), "GetDpiForWindow");
                                                                              ^
../src/platform/guiwin.cpp: In function 'BOOL SolveSpace::Platform::ssAdjustWindowRectExForDpi(LPRECT, DWORD, BOOL, DWORD, UINT)':
../src/platform/guiwin.cpp:93:87: warning: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'SolveSpace::Platform::LPFNADJUSTWINDOWRECTEXFORDPI' {aka 'int (*)(tagRECT*, long unsigned int, int, long unsigned int, unsigned int)'} [-Wcast-function-type]
             GetProcAddress(GetModuleHandleW(L"user32.dll"), "AdjustWindowRectExForDpi");

I fixed the warning in be0dc7e.

Now that I look closer at the window staying on top, well, there's code that does that:

What if you comment it out and rely on parent-child relationship?

That did it, the window abides as expected!

As a Windows user, which set of WS_* flags do you think SolveSpace should use?

Here's a video illustrating the issue: the scrolling code works fine, but the as the mouse is over the Property Browser window and scrolling, if there's any selectable face in the sketch window at the mouse's position, it will be highlighted, until the mouse is moved.

Regarding this bug, I think I know what causes it, as well as why I can't reproduce it. Can you open another issue so it doesn't get lost?

WS_POPUPWINDOW|WS_CAPTION are actually perfect, now that it doesn't linger!

To recheck, do I understand it correctly that without that code, the property browser window is still on top of the main window at all times, but now it is no longer on top of other windows when the main window is not in focus?

Yes

Fixed in 5dbe090.

Superb, thank you!