Atemu

You don't even need to wait for "AI" chips, "just" a high-end GPU will do.

You don't even need that. A decently high-end CPU will also work, just a good bit slower of course.

I sadly don't see how that could really work in a modern city because cargo trams can't just stand still on the track in order to unload because passenger trams can't go past them.

You'd have to build out additional rails for cargo stops everywhere.

Commonly used delivery vehicles (sprinters etc.) are quite dense w.r.t. cargo/m^2; they don't have the incredible density inefficiency problem of personal motor vehicles. They can also flexibly be temporarily parked on nearly every street in a way that at worst usually only partially blocks traffic and therefore don't really require special infrastructure.

Cargo trams would likely take more space for ...what upsides exactly? No seriously, what are the upsides?
For long distance cargo, trains' efficiency boons are obvious; long loading/unloading times are offset by the immense efficiency and speed.
For urban cargo transport with its short distances, non-standard routes and sometimes very frequent stops, I fail to see how trams would be a good fit.

Intel and AMD are so similar, they may aswell be the same platform. The only real difference is the iGPU where Intel has an edge in terms of transcoding quality.

I wouldn't buy anything new or recently released for a modest home server. I don't think you can get really good deals on alder lake CPUs yet, so I don't think you need to worry about efficiency cores.
Any CPU made in the last decade or so can do virtualisation just fine.

I haven't looked into this in detail yet but, for WAPs, I'd buy something that can run OpenWRT.
For firewall/gateway, it highly depends on your internet connection. If you have fiber terminated to copper, you could use anything that has an Ethernet port but with DSL or DOCSIS, your only reasonably choice is likely a SOHO router. In that case, I'd also look into getting one that can run OPNSense or OpenWRT depending on your taste.

Improper use of sysrq can absolutely lead to a borked system or other breakages as it allows you to initiate unclean shutdowns or kill all processes which can have consequences.

If your system is stuck though, sysrq is often your only option short of hardware shutdown.

Your system stops responding even if it's not booted from those drives but a live ISO?

There are some obvious security risks involved in fully enabling the SysRq key. In addition to forcing reboots and the like, it can be used to dump the contents of the CPU registers, which could theoretically reveal sensitive information. Since using it requires physical access to the system (unless you go out of your way), most desktop users will probably consider the level of risk acceptable. That said, make sure you fully understand the implications of enabling it and the dynamics of the larger context in which your system is operating before you turn SysRq all the way on.

https://wiki.archlinux.org/title/Keyboard_shortcuts#Enabling

I don't care about this so sysrq is enabled on all of my desktop systems.

Did you boot with the kernel flags from the log?

Could you show the dmesg from the point onwards when the drive dropped out?

I wouldn't be so sure about that. The Switch records a 720p30 video all the time for its 30s replay functionality that is on by default.

At least theoretically, capture and encoding themselves shouldn't cause any more performance issues than a stock Switch already has (unless you try to stream and have the replay buffer ofc.) and sending a bunch of video data over a network isn't very intensive.

I'd start by generating some synthetic workloads such as writing some sequential data to it and then reading it back a few times.

badblocks concerns partial failure of the device where (usually) just a few blocks misbehave while the rest remains accessible. The failure mode seen here is that the entire drive becomes inaccessible and it's likely not due to the drive itself but how it's connected.

If synthetic loads fail to reproduce the error, I'd put a filesystem on it and copy over some real data perhaps. Put on some load that mimics a real system somehow to try and get it to fail without the OS actually being ran off the drive.

This video explains it well: https://www.youtube.com/watch?v=RY_2gElt3SA

Boot a live ISO with the flags recommended in the kernel message and do some tests on the bare drives. That way you won't have the filesystem and subsequently the rest of the system giving out on you while you're debugging.

Distro doesn't really matter here. Choose any that you like.