Private trackers usually have a request mechanism that you can use. I currently use seedpool and digitalcore which let you request media after you've spent enough time seeding media
merthyr1831
MergerFS and SnapRAID could be good for you. It's not immediate parity like with ZFS RAID (You run a regular cronjob to calculate RAID parity) but it supports mismatched drive sizes, expansion of the pool at any time, and some other features that should be good for a media server where live parity isn't critical.
Proxmox and TrueNAS are nice because they help manage ZFS and other remote management within a nice UI but really you can just use Debian with SSH and do the same stuff. DietPi has a few nice utilities on top of Debian (DDNS manager and CLI fstab utilities, for example)but not super necessary.
Personally I use TrueNAS but I also used DietPi/Debian for years and both have benefits and it really matters what your workflow is. OMV supports everything you want too (incouding SnapRAID) but takes extra setup which put me off.
Docker or LXC containers won't hurt your performance btw. There's supposedly some tiny overhead but both are designed to use the basic Linux system as much as possible: they're way faster than on WSL. For hardware acceleration it'll be deferred to the GPU for most things and there's lots of documentation to set it up. The best thing about docker is that every application is kept separate to eachother - updates can be done incrementally and rollbacks are possible too!
My scepticism is that this should've been done within the coreutils project, or at least very closely affiliated. This isn't an area of the linux technical stack that we should tolerate being made distro-specific, especially when the licensing is controlled by a single organisation that famously picks and chooses its interpretation of "FOSS" to suit its profit margins.
On a purely technical level, GNU coreutils should very seriously consider moving to rust if only to counter alternatives before it's too late. While these utilities work well in C (and usually stay secure thanks to the Unix philosophy limiting the project scope), FOSS projects are continuing to struggle with finding new contributors as younger devs are more likely to use modern systems languages like Go and Rust. Not to mention that any project using Rust as a marketing tool will appeal to anyone rightfully concerned about hardening their system.
the new name is pretty slick so not all that bad