jrgd

If you take a look at it from the lens of distro maintainers, this would be an absolute nightmare. Distros package library versions, and currently tightly control the release of applications to given library versions. Allowing just any range of library versions for applications would loosen said requirement, but would require distros to then build and maintain a ton of versions of each library.

Flathub currently curbs this problem to a large extent by bundling explicit point release packages of common libraries, and expects the application to bundle uncommon ones themselves. This does mean that one cannot simply package an application without some thought put into the library versions used for release on Flathub still.

For distros, this style of packaging could somewhat be copied, but to little benefit. It would either be wasting time replicating congruence with an existing standard like Flathub’s library bundles or do their own thing and further complicate things for developers wanting to get their app published to a distro’s repos.

Overall, flatpaks make the process look a bit more seamless than things really are for developers and package maintainers. Flatpaks really only work as well as they do because everyone mostly agrees on adhering to the library packages published by Flathub. I don’t really think adding even the sliding scale of library ‘sets’ for various distros would any benefit beyond what is currently done.

Based on OP’s edit, that looks correct. Unless OP checks the topology and can make the claim that drives from the main chipset are the slow ones, secondary chipset drives will tend to perform slower, and the ASMedia ASM1061 has several reports online of poor to trash performance compared to baseline.

Best bet if the full performance is necessary out of every drive would be finding a decent quality PCI-E SATA III riser card that doesn’t use a known flawed driver chip rather use the two ‘extra’ ports on the motherboard.