A simplified view follows:

Previously: displays & input devices -> xorg-server -> compton -> window manager -> X11 protocol -> X11 clients

Now: displays & input devices -> wayland compositor -> wayland protocol -> wayland clients

So does that mean that if you wanted to port, say, Xmonad to Wayland, you would have to reimplement compositing logic again? (Since the existing compositing-logic implementation also handles things like window placement that you would want to override)

In theory, yes. In practice, you could build something on top of wlroots, which does a lot of the work for you. In fact, check this out:

https://github.com/swaywm/hsroots

Thank you for the clarifications :)

An X window manager would likely have to be completely rewritten to work on Wayland, I doubt many of them have much abstraction of the underlying window system.

I believe this is a result of wayland. The window manager now includes what you think of as compositing in the world of X11. The compositor just also happens to do the window placement. I think. I do not yet understand wayland, so if someone knows more I'd love if they shared.

edit: that was sort of correct. More info here: https://en.wikipedia.org/wiki/Wayland_(display_server_protoc...

Few years back when I was working with Wayland on a particular automotive project I came up with an explanation we could use with those outside the project.

Wayland is a protocol, which isn't really instructive. But the reference implementation, libwayland, is easier to comprehend. You can think of libwayland as a library for writing window managers directly on the framebuffer. Sure - that's a lie, but it's a helpful lie.