[crashdancer]

>I think it's fair to say, though that GTK4+libadwaita is "the GNOME toolkit", and GTK4 alone is just a much less capable, less extensible, less "batteries included" toolkit than GTK3

Your example shows the opposite though. GtkSocket & GtkPlug were removed because they were buggy and never worked on any non-X11 platforms. Removing platform-specific hacks and moving towards standard interfaces is the correct way to go if you want a generic "batteries included" toolkit and not just something that can be used to hack things together on specific Unix platforms using a specific outdated window system.

I doubt anyone has any actual interest in making it work in GTK4 because XEmbed is a pretty broken concept full of race conditions that was never fully implemented anyway. And design-wise XEmbed doesn't actually make any sense because you need to funnel everything through the X server just for one app to host another one. The proper way to do it is to have the Socket be a server and make the Plug a client that talks directly to it through its own socket. I imagine your Wayland solution does this by running a small pass-through Wayland server. That should get easier over time as Wayland libraries improve, which I can't say about XEmbed because X11 isn't being developed anymore. Doing something like that is also AFAIK the only way it would work on MacOS.

Regardless, the GTK developers probably won't merge any replacement for Socket/Plug unless it works on all supported platforms including Windows and Mac, and it actually fixes all the bugs that were in XEmbed. And you have to ask the question: why is this needed anyway? In my experience this isn't a general-purpose feature, the huge majority of apps work better when whatever embedded widget is put in a shared library, or uses RPC (i.e. D-Bus) calls to populate its own in-process views.