Also, using C++ has vtable/exception overhead. No-go.

That’s just nonsense. The kernel and most other big C projects are full of structs with manual re-implementations of vtables.

If you don’t want exceptions (I don’t either), C++ doesn’t require you to use them. KDE software builds without them.

Mostly, a good library on C++ (Qt used to be one of those, but it’s started becoming annoying in the past few years) offers a lot of what Rust enforces at the language level.

I like C++, but let’s not pretend that’s actually true. Qt is completely full of really unsafe APIs, most of them quite old by now. It certainly doesn’t offer anywhere close to any safety Rust provides.

Even something as innocent as passing a pointer to Qt’s javascript engine can end up in use after free, and the signal+slot stuff goes wrong real fast once you do need multi threading.

(which is not to single out Qt specifically, the STL has plenty of really stupid and unsafe APIs as well)

xdotool should work the same in the Wayland session, assuming you give X11 apps the permission to emulate input. What about it isn’t working?

uinput is not the proper way, it’s emulating a hardware device.

The remote desktop portal is the proper way. Even xdotool works through that.

Plasma widgets are a gaping security hole.

Aka “thing that isn’t sandboxed, never has been sandboxed, and never has been claimed to be sandboxed, is in fact not sandboxed”. Just like any app from your distro repositories, or appimages, or games in Steam… Or even most Flatpaks by default for that matter.

Widgets being sandboxed would be cool and is a long term goal (which is way easier said than done!), but don’t present them not being sandboxed as some irresponsible thing someone does because they don’t care. Your expectations of security simply are simply completely misplaced.

Wayland as a protocol was designed around CSDs, protocols for SSDs came years later

That’s not an argument for anything. The core protocol isn’t useful on its own, you always need extensions that came later to even create a window. As another example, Wayland as a protocol was designed around shared memory buffers, protocols for hardware acceleration came later. Doesn’t mean you’re supposed to leave that out.

Modern apps tend to prefer CSDs anyway since it provides more flexibility, very common on MacOS and Windows

That too is not an argument for not implementing what a ton of apps need.

MacOS and Windows don’t do the same sort of CSD as Gnome FYI, it’s more of a hybrid approach, where parts of the decoration are rendered by the system and parts by the app.

It’s difficult to coordinate things between the client and compositor.

That too isn’t relevant, libdecor doesn’t coordinate shit either. And if you want to (which is being looked into), you can absolutely sync things with SSD too.

The actual and only reason Gnome doesn’t support SSD is that they think CSD is a “better architecture”.