"I can't stop the heterocyclic declination!" (TNG: "Samaritan Snare")

For a while I daily drove a Purism Librem 14 with Debian's fully free kernel, and installed as few non-free packages as possible, including firmware blobs (which I didn't install any of until I decided I needed Bluetooth). My experience with gaming was generally fine.

With linux-libre you really have to buy your hardware specifically with support in mind. You're limited to Intel and non-bleeding-edge AMD graphics cards, a very small range of wifi cards, and no Bluetooth. Otherwise, video games should work as well as they would on any other computers with the same specs. Especially if you're also limiting yourself to games with free engines - I'm not aware of a single libre game that demands more than a modern Intel integrated graphics card can provide, even on high settings.

I've never used these, but I've come across them while scrolling through F-Droid and they seem to fit this use case:

Kotatsu
Kinoko

I personally don't use Arch, but I think the reason so many people find it stable in practice is because they know their system well. When something breaks or needs to be changed, they know which configuration file to edit, which package to {un,re,}install, what to look for in the AUR, etc., and they can usually avoid those things in the first place, because they went through a fairly hands-on install process, not to mention having the best Linux wiki in existence at their disposal.

On top of that, I think a lot of derivatives of Debian, including Ubuntu and all its derivatives, severely undermine their stability by providing custom configurations for or changes to software that are rarely documented and completely transparent to the user... until they break and leave no indication of how to fix them. Which is one reason why I ended up using base Debian.

1. I believe there is still an issue with Windows deleting Linux bootloaders during some updates. You'll be fine if you install Linux on a separate disk, and even if you dual-boot on one disk and the bootloader gets deleted, there are ways to recover it. You don't strictly need to have separate data and OS partitions, and I've gone back and forth on whether I prefer it - it makes distro hopping and disk encryption easier, at the cost of potentially inefficient use of space and serious consequences if your OS partition fills up.
2. Disk encryption is very straightforward if you use separate OS and data partitions. You literally just tick a box during the install and enter an extra password. It won't upset Windows any more than a normal install does (i.e. Windows might think it's corrupted, but won't do anything without your input). With one partition for everything, it's still possible, but the encryption will be much weaker and handled by the bootloader in a somewhat clunkier way, and I'm not sure if Mint even supports that setup.
3. I don't have much experience with this myself, and certainly not on Linux Mint, so I'll leave this one to other commenters.
4. Synaptic is just a fancy frontend to APT, and I think Mint also has something called mintInstall, which was just an apt frontend back when I used it, but I think it also supports Flatpak now. It's entirely up to personal preference as to which UI you prefer. I do recommend you set up Flathub if it's not there by default, as it gives you access to a ton of useful apps that can't be packaged by Debian, Ubuntu, and Mint for various reasons.
5. Don't download software from random websites unless it's absolutely necessary. Chances are, their version either won't work well, if at all, or will break your system. Try APT first, Flatpak second, everything else is a last resort option. If a program you used on Windows doesn't have a (working, native) Linux version, try finding and learning to use an alternative that is in the APT repositories before downloading the Windows version and using it on Wine. Back up your most important files from Windows before installing Linux in dual boot, just in case you make a mistake somewhere. To answer the last question, stick to the default terminal emulator and Firefox installation unless there's a feature you really want in another one; the distro's developers picked them for a reason, after all.

VLC's file format support is amazing for a project that rolls its own codecs, etc, but it's missing some important features for me on the music front, primarily gapless playback and library management. I generally prefer to use software tailored to my DE. I've yet to find a better video player anywhere though; GNOME Videos and Kaffeine come closest and are a little easier to use, but are still far away from VLC's capabilities.

I still follow Planet KDE and Planet Debian, and can vouch for both. They're great for both learning about the development processes of those projects, and finding interesting blogs on unrelated topics that happen to have been written or linked by the contributors.

I find it really fun to browse the Debian repository and its source code with their dedicated websites for doing so ( https://packages.debian.org/ and https://sources.debian.org/ ), to find all the obscure utilities, and silly code comments.

oregano

Debian Stable. It doesn't break with updates, it doesn't break when I try to customize it, it has all the software you could ever want, and it just works. It's robust, elegant, and free forever.

For most people I'd recommend a derivative like Mint, Q4OS, or SpiralLinux, since those smooth out a sometimes annoying setup process, but for me vanilla Debian is perfect.

James T. Kirk acted as if the Temporal Prime Directive didn't exist. Kathryn Janeway knew it existed but actively didn't give a fuck.

Depends on a few factors, AFAIK as a non-lawyer. If the license allows closed-source derivatives (i.e. is permissive rather than copyleft), then anyone can create a closed-source version with all of the contributors' changes, including the original maintainer. And anyone can choose to keep it open-source. The community contributions still to some extent belong to the contributors, though the license waives most of their rights.

Some projects are copyleft, but contributors are required to sign a license agreement (a CLA) which allows a single entity to change the license as they desire, including to closed-source - this is a good reason to avoid such projects. The contributors don't own their work in such a case, but they can still fork the old project as it was before being taken closed source.

In a copyleft (e.g. GPL) project with no CLA, it's illegal for anyone to make a closed-source version, and a major contributor could sue even the maintainer for doing so.

In all such cases, the change to a closed-source model does not erase the existence of the open-source code with community contributions. A fork is always possible.