The problem there is that the Wayland protocol family is not tolerant of dropping events or buffering them indefinitely, so there is no benefit to an X server-l

The problem there is that the Wayland protocol family is not tolerant of dropping events or buffering them indefinitely, so there is no benefit to an X server-like architecture where you can transparently restart or replace the compositor. You're welcome to try, of course, but there are an incredible number of scenarios that break clients; one off the top of my head is if the mouse cursor creates a client tooltip by hovering over some GUI element, then leaves that region while there is no compositor to handle the mouse movement events. You're going to end up in a world where you're synthesizing fake events to "reset" the state of clients, and this is dragons-at-the-edge-of-the-map territory. I wish Wayland was architected around a state-synchronization model instead of being event-driven. It'd be extremely difficult to port client toolkits and would ultimately fail to attract adoption, of course, but you'd end up with a more resilient system overall, and one that could be a bit more implementation-agnostic.