It’s difficult to know how much of a difference it makes, but I also think it’s at least a reason. Given Nintendo is also going after sites like Vimm’s Lair, which does not host recent consoles ROMs, it’s not the only reason.

Yes. 1TB SSDs can be bought new for 50€, 500GB for even less. For some people this is expensive depending in the region (e.g. I also know someone who uses an HDD). But given the price of other pc parts it isn’t something to cheap out on (a 1TB/2TB HDD is also 50€).

Global hotkeys have been addressed on KDE, but no applications actually support it — one of the reasons being that no other desktops support it. Typical chicken-egg problem.

IIRC the acceleration curves supported by Sway are the same as libinput, at least that’s how I understood the poor pieces of Dokumentation I found [1]. I don’t think think libinput supports offsets and upper limits, so it’s not really useful for gaming.

I’d recommend going with leetmouse, which does work well (altough I don’t use it anymore).

leetmouse by systemofapwne is more up to date and includes the PR of N-R-K [2].

[1] https://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html#ptraccel-profile-custom

[2] https://github.com/systemofapwne/leetmouse

Most people using these sites prefer the lossless codec flac anyway, which can be transcoded to anything.

MP3 320kbps and MP3 V0 is transparent to most (all?) people, so there’s not much of a reason to go with a newer codec, except for space savings.

There’s not even much of a reason to go with 320kbps, as V0 achieves the same quality with smaller files. That’s why almost nobody actually downloads MP3 320.

I personally think MP3 is there for historical reasons, as I don’t see a reason for using lossy codecs for archiving purposes. Just download flac and transcode it once or on demand on a media server for streaming.

tl;dr
Read the first sentence after each citation ;D

So Wayland, a protocol, is needing the addition of other protocols?

Yes. What we know as Wayland is the Wayland core protocol and a few other protocols that are absolutely necessary for desktop use (stable).

Then there is staging, which is not necessarily implemented by all compositors, e.g. fractional scaling.

Unstable also exists, which is even easier to get a protocol into (idk the exact requirements, likely the amount of support and explicit dislike by contributors).
These are often only used by a subset of compositors with e.g. XDG decoration allowing compositors to announce to clients (windows) that they support server side decorations (top bar with close/minimize/maximize buttons). This isn’t implemented by Gnome, but most other desktops support it.

Different desktops also have their own protocols, which are published so that apps targeting those desktops can implement them. Some are also supported by other desktops, if they think they are suitable for them.
E.g. wlr layer shell makes status bars possible, which are used by basic compositors like Sway or Wayfire. KDE also supports it, even though it was originally created by wlroots.

Does this make it a Wayland Distro?

In a way you could say that a compositor is a Wayland distro, as it implements a subset of Wayland protocols.

In the end this is good, because it allows for rapid development and discontinuation of protocols. E.g. if a better protocol comes around, both protocols can be supported at the discretion of every compositor.

The goal was to solve the problem of X11, where Xorg still has to support drawing UI by itself, even though no program or toolkit uses it anymore (the 80s were very different). The Wayland core is so minimal there shouldn’t be any issue with using it for a very long time.

Also, Wayland was developed by people with the goal to use it in automotive and other industry applications, where basic desktop functionalities, like multiple windows or session lock, aren’t useful.

Unencrypted messages are useful for very large rooms, where encryption doesn’t provide meaningful more privacy since public rooms have to be considered public space anyway. Encryption does have overhead, so it makes sense to disable it.

Private rooms are E2EE by default and can’t be created unencrypted (at least in the Element X mobile UI). This is a good way to handle it IMO.