To be completely pedantic, I don't believe the Wayland protocol itself actually dictates a design like this: you can separate the Wayland server from the compositor and display server bits if you want. I am not aware of many implementations of this, though; the best example is probably still Arcan.

That said, the very vast majority of Wayland compositors, including Mutter, Weston and everything using wlroots, is implemented without separation between the display server, compositor, etc. so in practice this is still mostly true, it just needn't remain true into the future.

You're right, of course, and I should've been more precise about that given I have looked at doing exactly that myself (main thing stopping me: I was able to switch to my own X11 window manager within a day - it was painful but worked; meanwhile I'd locked up my machine's display hard within 5 minutes of running some DRI/GBM test code and had to reboot)

I do think, ironically, that the future of Wayland will involve making it more X-like - adding WM support, maybe stripping back the exceedingly overcomplicated protocol (my window manager is smaller than most Wayland example clients..)

And thanks to the extensibility of the Wayland protocol, you can layer any X functionality right back in...