Hey, I recognize that art! That's the Pepper & Carrot guy! iirc, that's a FOS webcomic (CC BY 4.0 license, artwork and transcripts available for each episode). We need more people like him: using FOSS to create FOS media and contributing to the community with write-ups and guides; what a mensch.
I haven't had many issues with wayland, but there are a few sticking points, and it's usually when you get into the weeds like this. Wayland is ready for mainstream release because all the software that gets the most use is taken care of already, but when it comes to niche edge-cases, it still has a long ways to go; and it will take a lot longer to "get there" all across the board, given how uncommon it is for the already relatively small amount of people doing the edge-case work to also either have time enough to walk devs through the issues or have enough coding knowledge to contribute to the software directly.
I recommend using defaults unless you do disk-level backups, or plan on switching disks/partitions between systems (you can put your whole /home dir on a NAS, but should you?)
Yes*. Many such cases.
*there's always a reason why it was preventable (as the top comment on that post explains), but c'mon... Really?
Probably not, for reasons I explained above
It's straight-forward-ish. It will require deviating from installer defaults, and depends on how interconnected you want the OSes to be.
This is actually a good reason to get into partitioning shenanigans, if you'll use all the distros regularly, and you want them to have shared access to certain folders (e.g. /root, /var, /home, /tmp, /etc, etc). I recommend turning everything (except windows, /boot and /boot/efi) into logical volumes with LVS to avoid space issues when you can't extend a partition sandwiched in between two others.
By default, /boot and /boot/efi should be their own partitions--/boot should be created for Linux, and Linux will use the EFI partition created by micro$oft--and I'd recommend giving /boot N times the default amount of space (N being the number of distros you plan on keeping in rotation at any given time); this shouldn't eat up too much space, Debian gave me 500 MB for /boot. The reason being /boot carries the kernel images for each and every OS, and often duplicates thereof for rescue backups.
Yes it's easy with LUKS. Full disk encryption encrypts everything, and that will likely upset windows, idk haven't tried on my dual-boot.
Yes, if you use a DE with it integrated. Otherwise, it's up to you to choose the right software, rclone looks like a good choice to me, but I have not used it
synaptic is no longer used iirc. It's just called "Software Manager," but yes, I believe it's just a GUI for apt. I personally prefer doing as much as I can with the command line. Not only is it the simplest, most straightforward way of achieving whatever I'm trying to do, it's usually also the quickest and best documented. YMMV
My experience has been to avoid non-defaults as much as possible. If there's a software you can only get as a flatpak and you need that and can't make do with an alternative, then do it. Otherwise, just see what you can do with the apt repositories
I could spend a few hours digging up every mistake I made and telling you what not to do, but I'd rather focus on giving you the tools to clean up after yourself when you make your own. The one best piece of advice I can give is "keep at it." There will be times when you shoot yourself in the foot and your options are to give up and lose the foot or do foot surgery right then on your own (with the help of the online community ofc). Don't be afraid to ask questions everywhere or anywhere, don't let assholes dissuade you from enjoying your Linux your way or seeking help doing so, and do read the docs. But most importantly, do keep trying; it's such a rewarding feeling.
Another would be to change as little as possible from a known working configuration at a time. Go with installer defaults as much as you can, change the stuff later. Want to try out new software? Try one new thing and get it working and looking how you envision before moving on. Read the docs so you don't take any settings for granted, that way you're not left with something that's passable instead of exactly what you want.
Make backups. Get a second SSD or an external drive and backup your system. Things like /usr, /etc, /root, and /home at the very minimum. Backups are the best way to unfuck your foot when you inevitably shoot it.
Learn the coreutils. You might not use them daily, but you'll be glad you know they're there when you need them and don't have to install extraneous software that isn't well maintained because it's a redundancy of the most common pieces of linux software.
Learn the FHS. As with most documentation, it's a bit dry, but very enlightening and will automatically put you in the top 10% of linux users with your newfound special knowledge.
There are some automatic file organizers, but you can recreate them yourself to suit your exact needs at 1/10th the resource cost using bash scripts.
Sidebar: another good piece of advice, learn to script in Bash. It basically immediately qualifies you to be a *nix sysadmin, and it makes everything automatable. It's so much easier than downloading new software or compiling a git repo for each individual task you want to automate. Additionally, it helps to learn to use cron, to run the scripts automatically, and to learn a command-line text editor (no, nano does not count)--but those're mostly just for efficiency boost, the big timesaves are in learning to script first and foremost.
As with any skill, the common wisdom is to "choose a project you want to make, then learn the skill by making it." So it's not a bad idea to learn scripting by, say, writing a script that detects files of a certain format in a directory tree and moving them elsewhere. E.g. check ~/Downloads and all of its subfolders for files ending in .jpg, then move them to ~/Pictures/JPGs (and make the directory if it's not already there). This should give you a good chance to practice file operations and string manipulation/parsing. After that, learn how to have cron run it once a week or something.
This just falls under my "probably best to stick with defaults and branch out later" advice, but:
I use terminator, purely because it has a logger plugin (which saves all input and output, including stderr, into a file if I'm doing something that needs that much documenting). I'd say learn to use tmux at some point as well, but that's just because I like moving my hand between keyboard and mouse as little as possible.
As for firefox, vanilla has always worked for me. It's not private enough for some people, so they will recommend something like LibreWolf or even Tor. On my laptop (which is completely keyboard driven so I can avoid using a touchpad) I use qutebrowser; it's not as full-featured (i wouldn't use it for video streaming), but it avoids using a mouse.