Wayland is so slowed by their errors in design that it's hard to really say when it can truly replace xorg. Their whole thing, which after typing that, I honestly believe is that the primary developer, who was a primary Xorg developer, simply did not want to carry the burden for the rest of his life of supporting software like he has had to do with Xorg, so he washed his hands of all responsibility, with the 'wayland is a specification' stuff, and 'compton is only a reference implementation of wayland', again, to avoid actually making something that has to be maintained and debugged. That's what makes it a true nightmare, every compositor can introduce its own bugs, the spec can have bugs, and now it's impossible to say, ok, we can fix this because we know where the bug comes from.
The only way you can use wayland, not an xorg wayland, is if you never use any xorg programs, only stuff made to work on wayland. That's basically not possible to do. So all the desktop data you see in -Ga from wayland users is actually using xorg reporting tools, like xprop, glxinfo, Xorg.0.log, xdpyinfo, xrandr - notice all the 'x' there? all Xorg tools.
Systemd.... sigh, did it make it better or worse? I can say, for a good solid 10 years, it made my dev life worse, since I couldn't do safe upgrades due to the bugs in systemd, those seem to be, now, finally, roughly ironed out, that took way too long because the main systemd devs kept saying they wouldn't fix the bugs, and denied they were bugs. Systemd is not really used by inxi, it's very slow and I try to avoid various systemd tools because they are just super slow, absurdly so in some cases.
Now what really worked, and is getting better all the time, is /sys data, that's from the kernel, /sys data improves yearly, and lets inxi do more and more stuff with no dependencies at all, the kernel guys have always been super good about creating highly usable live kernel data, like the stuff in /proc, and then in /sys, to me, that's one area where flat out they shine, best in class, nobody does it better. BSDs should have copied that idea long ago, but failed to. The basic idea is so simple, the essence of unix like systems is to be made out of files, so what better way to present system data than as virtual files? that's files made live by the kernel when you request it or read it. I am truly puzzled by why the BSDs didn't take this idea and run with it, because stuff like /proc/partitions, /proc/cpuinfo, /proc/meminfo, are simply better ideas, more flexible, easy to implement, and don't require compromising a single thing for BSD licensing or anything, these were just excellent engineering ideas, made for excellent reasons, and designed so well that they have been largely stable for possibly decades now.
This is something good engineers should have gotten together about and said, we need to do this too, these are just too good, but BSDs totally failed to do so, I do not understand why that happened to be honest. Not calling it /proc or /sys, just a virtual file system that you can read in a predictable, consistent, way, across operating systems, that was one of the things that linux did that helped them take over from bsds, and I don't understand why something this elementary is too much for the bsd guys to do. Sure they have sysctl -a, but that's not consistent across OSes, and it's unreliable, and not that well done imo, but it was a start, but they dropped the balll big time, which makes supporting them much harder than it should be.
Re systemd, I finally found out what caused the drastic failures, I was reading something from I think runnit or s6 types, and they explained the issue more clearly than I'd ever read, systemd, in a foolish attempt to try to optimize and speed boottimes, parallelized so much that sometimes the system would hit a boot situation where it literally did not know even how to print out a console screen, it was totally jumbled. This was a design error that I think was finally fixed, but it took at least 10 years too long to fix it.
But systemd toolsl no, they are slow, badly designed, and not appropriate for inxi use, I've checked them now and then, I do use a tiny subset, for example, systemd is the first tool queried to see if it's a virtual machine for the -M report if it didh't detect it any other way, there's a tiiny handful of other systemd specific things, bluetooth status for instance on systemctl containing systems comes from systemd, and it's report is actually quite good, maybe the best one of all the init management tools I saw, the most useful data, so sometimes it's pretty good, I have to be fair.