> A local file is not the same thing as a remote file
That's actually the easy case. Remote files are not local files, but local files are remote files: or more precisely, local files are a special case of remote files from the point of view of file access. If your filesystem API starts with the assumption that files are remote and must be handled as if they are remote, then you get pretty good local file access for free, as HTTP has been demonstrating for a couple of decades now. Of course if you instead start with the assumption that files are local and thus it's safe to do blocking I/O on them then when you add remote files you'll end up with an NFS-like mess instead. That doesn't prove that abstraction and generalisation can't work cleanly, it just shows that you were looking through the wrong end of the telescope. (Really, the distinction here isn't truly between remote and local but between unreliable and reliable. All remote file access may be unreliable, but it's certainly not the case that all local file access is reliable, or should be expected to be reliable. Especially not when you bring in user-space filesystems, as Plan 9 does.) Apparently Plan 9 actually started with a blocking-I/O-plus-thread-spawning model which was only so-so before it was fixed up: http://pdos.csail.mit.edu/papers/plan9:jmhickey-meng.pdf .
That's actually the easy case. Remote files are not local files, but local files are remote files: or more precisely, local files are a special case of remote files from the point of view of file access. If your filesystem API starts with the assumption that files are remote and must be handled as if they are remote, then you get pretty good local file access for free, as HTTP has been demonstrating for a couple of decades now. Of course if you instead start with the assumption that files are local and thus it's safe to do blocking I/O on them then when you add remote files you'll end up with an NFS-like mess instead. That doesn't prove that abstraction and generalisation can't work cleanly, it just shows that you were looking through the wrong end of the telescope. (Really, the distinction here isn't truly between remote and local but between unreliable and reliable. All remote file access may be unreliable, but it's certainly not the case that all local file access is reliable, or should be expected to be reliable. Especially not when you bring in user-space filesystems, as Plan 9 does.) Apparently Plan 9 actually started with a blocking-I/O-plus-thread-spawning model which was only so-so before it was fixed up: http://pdos.csail.mit.edu/papers/plan9:jmhickey-meng.pdf .