Except that window management is tightly coupled to display management.

The Mir developers seem to at least seem to care about software modularity.

Yes, it is, both in general and in Wayland.

Specifically, what would once have been called just a window manager now needs to be a compositing manager, managing window contents and compositing them onto the screen. That compositing manager also needs to handle input, since input depends on where, how, and if windows are rendered. And once you're handling all of that, there's nothing useful left that corresponds to an X server other than graphics memory buffer management, which is the kernel's job these days.

Wayland handles software modularity by providing a library for use by prospective compositing managers. Moving the compositing manager into a separate process from the thing actually doing the rendering does not add a useful form of modularity.

Citation? X11 window managers are decoupled from the rest of X and the OS by well-specified protocols.

That compositing manager also needs to handle input

Oh yes, I forgot how Wayland couples the WM to the OS as well.

Wayland handles software modularity by providing a library for use by prospective compositing managers. Moving the compositing manager into a separate process from the thing actually doing the rendering does not add a useful form of modularity.

1) Can you point me to an API specification for Wayland compositor libraries? If not, it's not decoupled.

2) Can one switch window managers without restarting the compositor (and thus losing window state) with Wayland? If not, it's missing a "useful form of modularity" provided by X11.

Software modularity is overrated, but in this case I think you got it wrong.