Although I am not by any means an expert on X11 protocol, I’ll give some sort of comparison to clarify some conceptual differences between X and Wayland.
Probably it’s pretty clear that Wayland compositors are themselves a display manager, but this doesn’t mean that it should be harder to develop a window manager (at least nowadays). Nonetheless, thinking about server-client architecture isn’t accurate when talking about Wayland compositors.
Another overlooked part are Wayland protocols, which are defined in XML files. While is not the same concept, think about message passing.
libwayland just encodes and decodes those messages, not caring about the actual implementation that is done by the compositor or the application toolkit.
Until not that long ago, there wasn’t any kind of standarization in the Wayland world, while X11 had for a long time clunky basic extensions like RandR and Xinerama. Although it’s not 1:1 feature-wise with X, Wayland has almost reach that point. With those protocols, features can be developed and implemented, and this is not a limitation of Wayland, that received wrong criticism about its usability and security design.
Before writing the XMonad compositor itself, first wlroots bindings should be done (check also
hsroots project). Ideally, those bindings should be XMonad agnostic. If I remember correctly, the identifier for X applications runing inside Wayland are called class, so
className should be refering only for X applications (it’s just an example, but maybe some breakage on config files should be expected at some point).
Despite all difficulties, it would be much easier to integrate with another DE (ex. KDE or XFCE panels) as long as they support the same protocol than wlroots (in this case, wlr-layer-shell protocol). That also applies for XMonad related projects like xmobar.
Hope that we keep discusing about more fine details, specifically about how to design and implement those in XMonad.