[ack_complete]

The dialog editor is a good example of the damage that was done with the VS.NET transition. When they rewrote it to use the WinForms-based UI, they introduced a fundamental bug: the Z-order for picking was reversed so that clicking on a stack of controls selected the one on the bottom. Very annoying for controls like group controls intended to be stacked below other controls. Bug filed, WONTFIX'd, and it's still broken to this day.

[zerr]

Afaik Win32 API explicitly states that overlapping sibling windows/controls is not supported.

[ack_complete]

No, overlapping sibling controls is absolutely supported in Win32. It has a defined Z-order for child controls along with functions to manage it:

> The system maintains the z-order in a single list. It adds windows to the z-order based on whether they are topmost windows, top-level windows, or child windows.

https://learn.microsoft.com/en-us/windows/win32/winmsg/windo...

The WS_CLIPSIBLINGS window style is also explicitly for controlling cross-clipping of child windows during painting:

> Clips child windows relative to each other; that is, when a particular child window receives a WM_PAINT message, the WS_CLIPSIBLINGS style clips all other overlapping child windows out of the region of the child window to be updated.

https://learn.microsoft.com/en-us/windows/win32/winmsg/windo...

Furthermore, group boxes and tab controls require overlapping child windows, because they are designed for the controls that visually appear within them to be sibling controls that are raised in Z-order. This is why the dialog editor's current behavior is broken, because the editor's picking behavior is opposite the drawing behavior and USER32's hit test order.

[zerr]

Right! It is wxWidgets that doesn't support overlapping siblings due to other back-ends (besides Win32) lacking support.