It's a nice idea. One possible implementation could use a Unix domain socket to communicate between client and server. Or even regular sockets to support network transparency. We can call the server X and after eleven versions end up where we are already.

X11 and wide idea of terminals go in hand. It's a problem of abstraction and platforms evolving. So I think, that you either end up with something like Web front-ends of today or something more structured, but far simpler like various TUIs or maybe Tcl/Tk with it's windowing shell wish. I think that some middle ground is possible, but hard and shifting quite fast.

I have liked the idea of NeWS for a very long time. Sadly NeWS was born and died long before it was viable: postscript has always been difficult to write a VM for and unfriendly to application programmers, machines were significantly slower, and NeWS itself was very much vendor-locked.

However, things are different now. We could embed Lua or WASM into the display server, and you'd have a much more programmer-friendly platform that can run efficiently enough to feel snappy. We have more memory, so you don't need to share toolkits between applications.

Maybe it's time to revive the concept.

Funny enough, Chrome Embedded Framework runs multiple processes to render the GUI. The main event loop is running in the host process, but there's others for GPU operations, etc.

You can already do that with X11, any X resource can be used by any process (caveats apply for security reasons, but for applications running locally it shouldn't be a problem) so you could simply pass a window ID to a child process via a pipe and then have it draw stuff on it.

possibly the elixir project Scenic? https://github.com/boydm/scenic