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.
