Right, the shift away from X doesn't mean the death of using GUI apps remotely, it just means moving to a Remote Desktop model instead of telling apps that their render target is your X server through a tunnel.
Seems like such a fundamental use case that should be made simple but is ignored (or made very difficult) by modern systems.
How all of this works on the backend is a combination of PipeWire to multiplex video sources and PulseAudio to multiplex audio sources.
There's nothing outright preventing something like X forwarding and https://mstoeckl.com/notes/gsoc/blog.html is a really cool project that makes it work.
From that author:
> The main difficulty in producing such a tool is that Wayland protocol messages primarily include control information, and the large data transfers of graphical applications are implemented through shared memory. waypipe must then identify and serialize changes to the shared memory buffers into messages to be transferred over a socket.
https://wiki.gnome.org/Projects/Mutter/RemoteDesktop
https://docs.kde.org/trunk5/en/kdenetwork/krfb/krfb-configur...
You most likely won't see an implementation "for Wayland" because that's like asking for a websocket implementation "for HTTP" the actual compositors that speak Wayland need to implement remote desktop capabilities and then expose an API for managing remote desktop sessions (org.freedesktop.portal.RemoteDesktop) to programs that want to leverage it.