I can relate to your point. I know both Windows and Linux quite well and both have their strengths and weaknesses. Just to put it in perspective: You didn't say

I can relate to your point. I know both Windows and Linux quite well and both have their strengths and weaknesses. Just to put it in perspective: You didn't say why we need containers of multiple streams implemented at the filesystem level. Also, these alternative designs that you describe and that work so wonderfully are often seen through rose-tinted glasses. You've probably seen a few videos and became impressed what was possible such a long time ago. But you probably haven't actually used these things, so you can't experience the limitations. I hate many things about Linux, but there is a lot of development work where Linux is much stronger. A lot about the "minimal design" approach is still valid today, and I don't mean Dbus or Docker or Kubernetes or whatever, which I likely would hate if I actually knew them. In my view, the main problem about (Desktop) Linux is fragmentation and lack of standardization. A strong suit of Windows development is the APIs, at least the older ones that don't get deprecated after a year. There are useful APIs for everything related to a Desktop experience, and you can count on their existence as a developer. The lack of standardization is what makes it feel like sand. Apart from the simpler stuff (POSIX), there isn't a trustworthy authority that maintains stable APIs for a solid user experience, at least not APIs that I feel like using personally. > VMS' complex pathnames are the visible sign of an OS which natively understands that it's one node on a network, that currently-mounted disks can be mounted on more than one network nodes even if those nodes are running different OS versions on different CPU architectures. It's an OS that understands that a node name is a flexible concept that can apply to one machine, or to a cluster of them, and every command from (the equivalent of) `ping` to (the equivalent of) `ssh` can be addressed to a cluster and the nearest available machine will respond and the other end need never know it's not talking to one particular box. Are you sure you understand how the Unix filesystem (VFS) works? On Unix, a filepath is exactly what you say: a name that can identify a resource. There are distributed filesystem protocols that are of course portable, not dependent on CPU architecture or anything. I don't get what is your point about these Drive-Letter paths, they often create annoying complexity. I believe even NTFS has developed extensions to get rid of them. So, not that I think filepaths are beautifully easy to use on Unix, but they're much better than on Windows in my experience.