Its all about how an application goes from “I would like to display X on a screen” to how X actually gets displayed. Wayland is effectively a language (technically a protocol) that graphical applications can speak to describe how they would like to be drawn. It’s then up to a different program more deeply embedded in your OS to listen to and act on those instructions (this program is called a Wayland compositor). There’s a lot more to it (handling keyboard input monitor settings, etc), but that’s the general idea.

Wayland is a (relatively) new way of thinking about this process, that tries to take into account the wide variety of input and output devices that exist today, and also tries to mitigate some of the security risks that were inherent to previous approaches (before Wayland, it was very easy for one application to “look at” what was being displayed in a completely different app, or even to listen to what keys were being typed even when the app isn’t focussed).

Thing is, change is hard, doubly so in the consensus driven world of Linux/FOSS. So, until the last couple of years or so, adoption of Wayland was quite slow. Now we’re at the point where most things work at least as well in Wayland, but there’s still odd bits of software that either haven’t been ported, or that still rely on some features that don’t exist in Wayland, often because of the aforementioned security risks.