In (old, pre-compositor) X11, windows were rectangles on screen. Every normal X11 client could query all windows and their positions. Tools like slop were easy to implement: You can use it to interactively select one of the windows on the screen, e.g. to make a screenshot of that window. slop just queries the window under the mouse pointer, it can then highlight it and read its position. Done. (slop includes more bloat/eyecandy, but that’s beside the point.)

Afaik, that’s not possible on Wayland. slurp exists but there is no standard way (yet?) for it to query the window tree. It’s different for each Wayland compositor. slurp’s README includes an example for Sway; for dwl you need this patch; and selecting individual windows probably does not work at all on labwc (because those guys try to stick only to established protocols/standards – an admirable goal).

This is just a small example. I think things like these slow down Wayland progress/adoption a lot. You could get a lot more done on X11 because the rules weren’t so strict. On Wayland, everything has to become an official protocol (that each compositor then has to implement individually) or it’s going to be an incompatible, unofficial, compositor-specific solution.

Both approaches have pros and cons. Wayland is much more idealistic than the “wild west” of X11. The price is that it takes a hell of a lot more time and energy to push things forward on Wayland.