I think a difference in magnitude turns into a difference in kind. There's lots of systems where the unreliability of the underlying parts is low enough that it can be a simple matter of retrying quickly once or twice (bit flips in ECC RAM), and others where at least the unreliability is well-known enough that software has all learned to work around the leaky abstraction (like TCP. Although QUIC and other protocols show that maybe it's better to move the unreliability up a layer for more intelligent handling of the edge cases.)

But the unreliability of "the network" compared to "my SATA port" is a whole different ballgame. Filesystems are designed for the latter, and when software uses filesystems it generally expects a reliability guarantee that "the network" can't really provide. Especially on mobile internet, wifi, etc... And that's not even getting into places where NFS just can't do things that local filesystems can do (has anyone figured out how to make inotify/fsevents work?) and all the software that subtly breaks because of it.

I think "making an unreliable system emulate a reliable one = bad" is too simplistic a heuristic.

We do this all the time with things like ECC and retransmissions and packet recovery. This intrinsically is not bad at all, the question is: what abstraction does this expose to the higher layer.

With TCP the abstraction we expect is "pretty robust but has tail latencies, do not use for automotive networks or avionics" and that works out well. The right question IMO is always "what kind of tail behaviors does this expose, and are the consumers of the abstraction prepared for them".

> other than by cobbling together a lot of unreliable ones and hoping the emergent behaviour

No, there's math to calculate that without having to rely on hope.