Thanks, the overall approach looks good (note: I haven't done a detailed review). I like both this and !6107 in different ways, so if this is the direction you prefer, I am happy to move forward with it.
I have pushed some potential improvements to https://gitlab.winehq.org/afrantzis/wine/-/commits/wip/wayland-child-surface... (rebased on latest version).
Relatedly, I also cleaned up some changes to glmark2, which I have been using to manually test some more exotic nested/reparenting scenarios, and pushed them to https://github.com/glmark2/glmark2/tree/win32-nested (please read https://github.com/glmark2/glmark2/blob/win32-nested/README.win32-nested), in case it's useful for your testing.
I have found that on some compositors (e.g. kwin) this MR leads to issues with some of the glmark2 scenarios (whereas !6107 works fine), but I think it's actually the compositor's fault not dealing well with some of the subsurface detachment/attachments in this MR. Experimenting a bit, I found that if we ensure that the client surface does not have an attached buffer before creating a new wl_subsurface for it, then the issues go away, but this shouldn't be needed (Weston works fine for example). FWIW, last time I tried mutter it also didn't behave well with more complex subsurfaces scenarios, so I haven't been using it much for testing these MRs.