Huh, guess the 4 mouse clicks it takes to install any of the ~200 games in my GOG library through lutris, and have it work perfectly first-time doesn't count then?

Proton is (BSD licence) open-source, the only proprietary part is the steam API client library.

That's exactly the market they are in, because the Steam Deck exists.
They've been trying to make the model fly for some time (steam machines etc.), and if the now quite large library of *proprietary* games running on the deck (and by extension, GNU/Linux) is anything to go by, this time it's working.
The only real showstopper right now is "anti-cheat" rootkits, and frankly if you're willing to bear that nonsense for the sake of a "AAA" game, you're probably fine with running Windows SpyOS too.

Much as I dislike Steam, there's nothing "pay per play" about it beyond fairly basic (and easily defeated) purchase-check DRM.
Again, Steam runs on GNU/Linux because the Steam Deck runs GNU/Linux. That's not "testing", it's a shipping game system.
Whether valve is "interested" in desktop GNU/Linux is irrelevant to the end-user, as the deck is effectively PC hardware and anything that runs on it will also run on a desktop. Hell, the thing runs KDE FFS, it might as well *be* a GNU/Linux desktop.

As for the OP... there's so much ridiculous there I'm not sure where to start. "talibans"? BSD doesn't have a terminal? Don't know how CPU power management has worked for the last 20+ years or how to configure it, and think that makes some OS "better" than another... The mind boggles.
Yes, if you want to run BSD you will need to actually learn BSD. Also, the sky is (usually) blue, and not everyone considers steam games the be-all and end-all of "desktop" computing.

There's nothing quicker than 'man' (and 'apropos', to find the right manual), since those manuals are already on your system. '/' for string search in the viewer (it's pretty much just the 'less' pager).
More comprehensive manuals are often available with 'info', though that varies by package.

I still have no idea why everyone goes straight for random blog posts and online copies of manuals... 'man' is faster, available almost everywhere, and doesn't require a web browser.

It presents as a very niche attack vector, requiring a specific set of conditions and permissions. For most people it's irrelevant.

I'd suggest you do whatever you like. There's no real reason not to set 'nodev' on a non-root "media and documents" filesystem, so you might as well.

It instructs the kernel whether or not to honour the suid and cap_sys_admin bits on executables, what else is there to "expand on"?

Exploiting suid executables also requires specific conditions and root permissions at some point, but again, since disabling suid does no harm on a data filesystem, you might as well.

I highly doubt it. It was likely the lack of the 'user' flag, since that is exactly what it's for. 'rw' is a default mount option anyway.
It could also be some weirdness of your file manager of course, but since you didn't specify what you're using, in which desktop environment, or what kind of "Authentication dialogue" you saw, who would know.

One additional trap to be aware of: If you use the 'user' flag, only the user who mounted the filesystem will be allowed to unmount it. That means the combination of 'user' and 'auto' will likely result in root mounting the filesystem at boot, and authentication being required for an unprivileged user to unmount it later. See the 'users' and 'group' flags for alternatives.

For reference, entry for the 4TB spinning-rust RAID1 in my desktop is:

LABEL=rust                      /mnt/rust       ext4    noatime,user,noauto        0 2

Which results in:

/dev/md2 on /mnt/rust type ext4 (rw,nosuid,nodev,noexec,noatime,user)

And it mounts and unmounts just fine from a GUI file manager (dolphin), without elevated permissions.
Note:

So we don't need explicit noexec, nosuid, or nodev, and:

So most of the time you don't need to add explicit (filesystem specific) 'defaults' for ext4 either.

An OS installation doesn't "own" a filesystem in any way (unless it's ZFS, but I digress), *nix is a network OS at heart and permissions are all about users and groups.

Who can do what and where simply comes down to whether the users effective UID/GID (i.e. numeric user and/or group identifier) matches the file/directory owner UID/GID.
If you set up your user account to have the same UID on both installs, that user will have the same permissions for the same files regardless of which OS you boot... And I suggest you do set up identical usernames with the same UID, because anything else is a kind of a confusing PITA (e.g. "bob" (UID 1000) on machine 1 can write to the disk, but "bob" (UID 1001) on machine 2 can't, so Bob is annoyed).

Aside:

No, no it should not. Mountpoint directory permissions should be root:root, they will be replaced with those of the root of the mounted filesystem (i.e. mount the filesystem, then chown, not the other way around).
Granting write on a mountpoint directory to an unprivileged user is just a super effective way to let that user fill up root when the filesystem is not mounted.

steve_v:
*opens a bunch of root-owned files in kate tabs, as unprivileged user*
*screws around for as long as needed, as unprivileged user*
*hits "save"*
*gets polkit authentication prompt*
*profits*

Much better than just having a GUI editor running as root for long periods of time I recon.

Aside, everything any of us might do in a GUI editor can also be done in emacs at a TTY.

The only thing more confusing here than the use of libreoffice for editing a simple text file... Is the use of libreoffice as root.
Just.. Why? Use a real text editor, from an elevated terminal. Nano, vi(m), emacs, mcedit, all work just fine without any weird encoding issues or the hazard of runing enormous GUI bloat as root. Nano has been the default $EDITOR for years, and with good reason.

Indeed, because that option simply specifies the number of parallel jobs to run. The only "error" possible is that the build fails because things are compiled out-of-order (which means upstream needs to fix their makefile / build process), and the only "risk" is wasting time and trying again with those options omitted.
To put it another way: The function of '-j' and friends is not complicated, and I have no idea why anyone would need handholding over such an option. Try it and find out, like everyone else.

The choice is whether to use DKMS or module-assistant... That choice is up to you.

Same as you would on Debian.
OTOH, compiling a kernel is much the same on any distro and hasn't changed significantly in decades, the only real difference here is using the debian specific make targets (included in linux-source-[version]) to build .deb packages rather than manually installing the image/modules.

And if you also fail to elaborate, nobody will know why.

Quite possibly

While I do run plain ALSA on systems that have no need for a sound-server, something of the latter nature (i.e pulseaudio or pipewire) is practically a requirement if you want "modern" GUI-centric on-the-fly source/sink and sample-rate switching for things like bluetooth audio peripherals.
ALSA can of course do most of that itself, but it's somewhat awkward and requires a bit of experimentation and messing about in poorly-documented configuration files... Which few can be bothered with any more, because much like the extended "I just copy-paste and hope it works" in this thread, "If I can't click on it, it doesn't exist" is apparently a thing.

Pipewire is also essentially unavoidable if you want desktop audio/video capture in a wayland session, and as with all the other functionality still missing from the wayland spec, that's the way freedesktop intended it.

In laptops it's often remote. Follow the wires to the battery wrapped in shrink-sleeve stuffed in some random corner of the chassis.
There's a small chance this could have an integral battery (e.g. some variant of the infamous Dallas RTC chip), but I doubt it. Either way, it's likely dead by now. Open the machine up and have a look, it's probably obvious.

Or a dodgy connection, as the error message indicates. Oxidation and/or general crud in SATA connectors can lead to all manner of fun.

Likely close enough, assuming that the live media has ntfs and/or fat (you don't say what filesystem you're running) fsck tools.
That said, a filesystem check probably isn't what you want for suspected hardware problems anyway. Pull the SMART diagnostics from the drive, then run a long (media read) self-test or badblocks. See 'man smartctl' and 'man badblocks' respectively. Both are considerably slower and more thorough than chkdsk.

Probably. Really not sure why we're talking about Windoze and Windoze filesystem tools to begin with though.

Aside, also really not sure why all the buggering about with an old mechanical hard drive.  It'll be miserably slow compared to even the cheapest SSD, and considering its age there's a very good chance it's just plain dodgy.

I suggest you forget about the original drive and software (i.e. image the drive if there's stuff you want on it, then bin it), slap some cheap second-hand RAM and a bargain-basement SATA SSD in, then move on to getting a real OS installed.
The box is not worth the time and effort trying to source "officially supported" or branded components, and messing with 20 year old hard drives is a mugs game unless you're restoring rare vintage hardware... which this is not.

No. For some truly bizarre reason Debian (and by extension Devuan) enables apparmor by default, but doesn't ship a default configuration for it that actually works properly.
Ignore it, disable it, or fix whatever it's moaning about, your choice.

The former will likely be the chipset limitation (which can be confirmed elsewhere, e.g. intel docs), the latter will be configurations the OEM tested with.
It's not particularly uncommon for a board to support, at least theoretically, DIMMs that weren't readily available when it was released.

As for getting some, I usually just go to ebay for stuff like this, and eat the (fairly reasonable for small items like memory) shipping (to NZ).

And what makes you think nftables is a daemon?

512MB is fine for a netinstall, though the live desktop will likely choke. What it's not good enough for is pretty much any modern graphical web browser.
Frankly, for anything <2GB I wouldn't be running a full DE (even XFCE), and for <1GB It'd be a straight-up CLI-only install.

That's not to say you can't run a GUI with 512MB RAM, just that you probably won't like it very much.

As already suggested, make sure the drive boots on something else... preferrably something more modern.
Blocksize shouldn't make any difference, and AFAIK XP didn't do any off-but-not-really-off "Fast startup" bollocks.

FWIW, I have found USB boot pretty hit-and-miss on machines from that era. There were several ways to make removable (CD, USB) devices bootable, and which worked with what BIOS was kinda down to luck.

Personally I'd just burn a CD, since that machine looks to have a fixed optical drive and CDs were still pretty much the standard install media at the time.
It'd also be interesting to try a bootable USB image from the period (e.g. knoppix or the like). If that works, you'd have somewhere to start with figuring out why the BIOS doesn't see the Devuan image as bootable.

I have Jessie (last release supporting i586) running on a K6-2 from ~1998. It's quite usable, so long as you don't do anything silly like trying to run a modern GUI.
I'm sure it'd run Daedalus too, if only the "i386" build still meant "i386".

IIRC I used PLOP on a floppy disc to boot the CD, because BIOS CD boot was flaky as all hell and USB boot hadn't been invented yet (also only USB 1.0, which would have been painfully slow anyway).