I agree the portals thing is a horrid mess, but you don't need them to take a screenshot unless you're a sandboxed application. Which is probably a good thing.

You can write a simple Wayland screenshot app with a few hundred lines of code[0], and a compositor that supports the ext-image-capture source and ext-image-copy-capture extensions implemented. (Or the older wlr-screencopy.)

I have plenty of criticism for Wayland and its ecosystem, but if you're going to criticize, don't spread FUD.

(I don't like being the guy who has to assert his credentials, but: I've implemented all three of those screenshot/screencast protocols in a Wayland compositor, just a month or so ago, and know how they work, and what it takes to talk to them from a client.)

Also I read through the link you posted. There's a lot of truth to many of those frustrations, but a lot of it is based on misunderstandings of what Wayland actually is. Yes, most people should be using a toolkit. No, it's not great that the main choices are GTK and Qt. I think there's absolutely room for a mid-level toolkit that lets you do the basics without requiring all the Wayland boilerplate. smithay-client-toolkit is one such effort, and I think it's a good start, though something even higher-level on top of it would be nice.

I also don't get the callback hate. I much prefer registering callbacks over a ginormous switch statement that has to dispatch every event under the sun. Toolkits use callbacks too; does the author hate all toolkits as well? You actually could talk to a Wayland compositor with a big switch statement if you wanted, though you'd need to modify libwayland-client to return events as you iterate its event queue rather than dispatch things to callbacks. That could be a fun project for someone who wanted to make Wayland event handling just like libX11 event handling. (See: just a fundamental misunderstanding of what Wayland is.)

And comparing raylib to libwayland-client is silly; they're fundamentally different things. And you can use raylib to talk to a Wayland compositor. It's just a bad-faith argument.

If you want to compare libwayland-client to something, you have to compare it to libX11 or libxcb. And while yes, getting a simple window on-screen is indeed simpler with libX11/libxcb, doing anything more complicated than that is on par with what you'd end up doing with libwayland-client.

[0] Not counting the protocol code that wayland-scanner will generate for you, because that's like saying you have to count the lines of code in libX11 to write an X11 screenshot app.