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.
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.
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.
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.