Apologies for the lengthy ramble, but I've got first-hand experience dealing with bitrot and a level of hardware knowledge to adequately explain what the deal is with it at least with flash memory, so I felt the need to do a sort of "info dump" to clear things up.
tl;dr: Specifically for bitrot on flash memory left unpowered, older is better, except when you get to non-3D TLC (usually from the mid-2010s) at which point newer (but also faster) is usually better but mainly because it's more likely to avoid the non-3D TLC stuff; otherwise bitrot susceptibility should have roughly leveled-off since the late 2010s (not accounting for
newer, fancier tech that can better resist bitrot of course).
Also back then, USBLGX wasn't spruced up for Flash drives.
Then I found a better a storage method in my search, & that was Micro SDXCs (in USB adapters).
Yeah, with r1280 and newer USB Loader GX natively supports loading Wii games from SD cards, so no need to go the adapter route any more unless you're like me and really want to use a 2GB SD card for any early Wii games that didn't support SDHC and don't appear to have a code or mod to add support for SDHC (for me that game is Excite Truck).
after Fat32 kept failing with my Flash drives, I searched for other ways & I had many micro SDHC/XC cards, & then eventually WBFS partition.
Wait, are you saying you never even tried FAT32 with the SD card + USB reader?
Thing is,, I also was having issues using USB flash drives back around 10-ish years ago (I had everything archived on a mechanical hard drive that "just worked", but it wasn't very portable nor robust for transport, and was actually much larger at 750GB than I needed to hold all my games) and, since I have a PC gaming friend that I get a bunch of hand-me-down hardware from, I had a slew of low-capacities SSDs.
So, in a similar manner, I settled on using a SATA to USB adapter but with the disk still formatted as FAT32 and it's been flawless for the last 5-ish years it's been in operation... well, mostly. I don't know if it was bitrot or I just derped something up or maybe it's the same issue as Excite Truck, but Tiger Woods' PGA Tour 10 didn't want to load at one point but updating software and re-doing the disk image has simply made everything work.
Any storage media has a limited life-span, & that also applies to the data stored.
Though some media has lifetimes so long that it could be measured in decades or even percentage of human life time—early low-capacity flash in particular, like the NAND found in the Wii or in GameCube memory cards, or even the likes of 2GB SD cards from the mid 2000s are quite resiliant to bitrot thanks to a combination of being manufactured on a large transistor node (even the most cutting-edge CPUs at the time were only using 65nm when the Wii launched, with the Wii's CPU itself using a 90nm process) as well as completely predating TLC (3-bit) NAND and therefore being MLC (2-bit) NAND at max and very likely to even be SLC (1-bit) NAND.
If in doubt, do regular scans for media fails.
Well, yes, but bitrot doesn't show up as media failure. I have what I'm pretty sure is one of those now-rare mid-2010s non-3D TLC USB flash drive that was (and actually still is while waiting for cold weather to test) suffering from bitrot and the OS has no idea that there's any issue at all because any data actually written to the disk "just works" without issue.
Actual media failure behaves quite differently from bitrot and, at least in flash memory, doesn't tend to occur when just sitting around unused for a while (something that
can cause a hard drive to fail).
The only real fool-proof way to know if you're having bitrot is if you have a way to check the integrity of the data in question, like compared to checksums of the files (e.g. SHA256, SHA1, MD5, CRC32, etc) or simply trying to open the files in question and seeing incomplete data or the like. In the Unix-like world, there are even file systems like ZFS, Btrfs, and the upcoming BcacheFS that integrate checksumming that can then be used to detect for any incorrect checksums, meaning you can therefore set things up to have at least two copies of your data in some fashion (called "parity data") that can be used to automatically recover the bitrot'd data when it detects a mismatch between the checksum recorded when the file was last written to the disk and whatever that file's current checksum is (assuming the parity data hasn't
also suffered from bitrot of course!)
More so with older equipment.
Mechanical hard drives, sure. Flash memory? As stated, it's much more complicated.
Because larger transistors resist bitrot better, this means older flash memory can last longer before bitrot sets in, but is not actually inherent to its age—hypothetical modern 90nm flash memory would actually last
longer than the stuff from the mid-2000s. Similarly, because newer developments have figured out how to fit more bits onto a single flash memory cell, this automatically makes older flash memory that uses fewer bits per cell more resilient to bitrot. Again, therefore modern SLC NAND would be
more resilient to bitrot than older SLC NAND, but only if they were on the same node anyway due to manufacturing yield improving over time.
The closest thing to a long-term bitrot test I've had is a 256MB (not a typo) USB drive that had the same Parted Magic 2012-10-10 image on it for like a decade, and it never skipped a beat. Alternatively I could take a look at some flash-based game saves that I dumped over a decade ago now from (some) GBA carts or DS carts that I've admittedly not touched in a while and make sure the checksums still match up.
By contrast, my sister had a 16GB USB flash drive succumb to bitrot
twice in only 3 years, but it was stored in a car and therefore a warm environment (which, as I previously stated, accelerates bitrot), so that disk is officially being ran in my "bitrot test" as of August; the drive was purchased in a closeout sale for cheap at K-Mart and therefore the later mid-2010s, and therefore is quite likely more non-3D TLC NAND if not even QLC NAND; yet a
newer 32GB presumably 3D NAND flash drive had no bitrot in that same time period (in fact the 32GB drive was specifically an upgrade to the 16GB one, so it experienced darned near the exact same use-case in her car of write few, read many).
And the other USB drive I previously mentioned that succumbed to bitrot was my father's that he got from work in the earlier mid-2010s but had sit around for like 5 years, again likely being non-3D TLC, especially since it was actually pretty much the slowest USB flash drive we owned that measured its capacity in gigabytes which is key because more bits per cell is slower than if the very same NAND used fewer bits per cell. This also means that faster NAND is more likely to be using fewer bits per cell, but sometimes they can "cheat" and use something like SLC caching which is fast initially but the long-term data itself gets stored on TLC or even QLC NAND.
Just to clarify the point about 3D NAND, it's just a way to increase disk capacity without the need to use a smaller node size, so most modern 3D NAND doesn't go below something like 19nm and, even then, it's pretty common to have 3D NAND in the 20-30nm range just like early 2010s MLC SSDs (though, again, MLC is inherently more resilient to bitrot).
When it comes to flash memory that is receiving power though, all bets are off since, as I previously mentioned, better flash memory controllers could even account for and prevent bitrot from occurring, but things are way too ambiguous in the area of flash memory controllers to really know which ones are able to actually do this.
