Wayland does not support screen savers: it does not have any provision that allows screen savers to even exist in any meaningful way. If you value screen savers, that’s kind of a problem.
Adding screen savers to Wayland is not simply a matter of “port the XScreenSaver daemon”, because under the Wayland model, screen blanking and locking should not be a third-party user-space app; much of the logic must be embedded into the display manager itself. This is a good thing! It is a better model than what we have under X11.
But that means that accomplishing that task means not just writing code, but engaging with whatever passes for a standards body or design committee in the Wayland world, and that is… how shall I put this… not something that I personally feel highly motivated to do.
I think that’s the core of most X11 vs Wayland issues: the API changed and the system design has taken another approach, so the hacks that old software needed to use (because let’s be honest, the way XScreensaver implements a full screen override is kind of a hack) aren’t working anymore.
Screen locking in Wayland is actual locking, as in the system takes away control from the applicantions merely rendering to the screen, so the way the desktop works will definitely break most screensavers.
All in all the concept of a screensaver can still work without too much effort I think. Rather than let Mutter/Kwin lock the screen after a lack of activity, let the screensaver check if the user is idle (i.e. using the dbus API or by reading input through a daemon running as root), and make it spawn a fullscreen animation. When the user interrupts the screen through whatever means necessary, call the lock API of the Wayland compositor/window manager in use. Then wait a second (make sure the lock animation doesn’t unintentionally show open windows) and exit the fullscreen animation. I’m sure it can be made to work.