Note that the drive letter names from MS-DOS which persist into modern Windows are a red herring here. Drive letter names are not the best representation of a file system structure which has multiple roots. They are a strawman implementation of such a system.

A properly implemented filesystem that supports multiple roots would allow arbitrary naming for the volumes, like dvdrom:/path/to/file.avi. Such as system would get rid of the laughable user interface issues that plague Windows. For instance, if you plug in a device such as a camera, the Windows Explorer UI makes you believe that there is a device called Camera (or whatever), and that you have a path like \Camera\DCIM\.... However, if you cut and paste the textual version of this path, it doesn't actually work. IN a properly implemented system with multiple roots, it would be fine: there would be a camera:\DCIM\... path that is recognized uniformly at every level in the system. Moreover, if you ported over an old hard drive from an OLD PC, you would not be stuck with some drive letter name like F:, but rather you would be able to name it whatever you want, like old-disk:.

So, if Unix did have multiple roots in the filesystem structure, it would be done sanely like this, and not like in MS-DOS and Windows with one-letter drive names. In other words, let us only compare the Unix scheme to a good multi-root design.

So, why doesn't Unix have a sane multiple-roots implementation, in favor of sane one-root implementation? It's probably just for simplicity. Mount points provide all the functionality of being able to access volumes via names. There is no need to extend the namespace with an additional prefix syntax.

Mathematically speaking, any disjoint tree graph ("forest") can be joined by adding a root node and making the disjoint pieces its children.

Moreover, it is more flexible that the volumes do not have to be at the root level. Since there is no special syntax which denotes volume (it is just a path component), mount points can be anywhere. If you bring in three old disks to your machine, you can have them as /old-disk/one, /old-disk/two, etc. You can organize disks however you want, the way you organize files and directories.

Applications can be written which depend on paths, and the validity of paths can be maintained when the storage devices are reconfigured. For instance, applications can use well-known paths like /var/log and /var/lib. It's up to you whether /var/log and /var/lib are on the same disk volume or on separate ones. You can migrate a system to a new storage topology, while preserving the paths.

Mount points are a good idea, which is why Windows has had them since around Windows 2000.

Volume mount points are robust against system changes that occur when devices are added or removed from a computer. Microsoft Technet

Note that the drive letter names from MS-DOS which persist into modern Windows are a red herring here. Drive letter names are not the best representation of a file system structure which has multiple roots. They are a strawman implementation of such a system.

A properly implemented filesystem that supports multiple roots would allow arbitrary naming for the volumes, like dvdrom:/path/to/file.avi. Such as system would get rid of the laughable user interface issues that plague Windows. For instance, if you plug in a device such as a camera, the Windows Explorer UI makes you believe that there is a device called Camera (or whatever), and that you have a path like Computer\Camera\DCIM\.... However, if you cut and paste the textual version of this path out of Explorer, it doesn't actually work because some of the pathname components are a user interface fiction, not known to the underlying OS. IN a properly implemented system with multiple roots, it would be fine: there would be a camera:\DCIM\... path that is recognized uniformly at every level in the system. Moreover, if you ported over an old hard drive from an OLD PC, you would not be stuck with some drive letter name like F:, but rather you would be able to name it whatever you want, like old-disk:.

So, if Unix did have multiple roots in the filesystem structure, it would be done sanely like this, and not like in MS-DOS and Windows with one-letter drive names. In other words, let us only compare the Unix scheme to a good multi-root design.

So, why doesn't Unix have a sane multiple-roots implementation, in favor of sane one-root implementation? It's probably just for simplicity. Mount points provide all the functionality of being able to access volumes via names. There is no need to extend the namespace with an additional prefix syntax.

Mathematically speaking, any disjoint tree graph ("forest") can be joined by adding a root node and making the disjoint pieces its children.

Moreover, it is more flexible that the volumes do not have to be at the root level. Since there is no special syntax which denotes volume (it is just a path component), mount points can be anywhere. If you bring in three old disks to your machine, you can have them as /old-disk/one, /old-disk/two, etc. You can organize disks however you want, the way you organize files and directories.

Applications can be written which depend on paths, and the validity of paths can be maintained when the storage devices are reconfigured. For instance, applications can use well-known paths like /var/log and /var/lib. It's up to you whether /var/log and /var/lib are on the same disk volume or on separate ones. You can migrate a system to a new storage topology, while preserving the paths.

Mount points are a good idea, which is why Windows has had them since around Windows 2000.

Volume mount points are robust against system changes that occur when devices are added or removed from a computer. Microsoft Technet

Note that the drive letter names from MS-DOS which persist into modern Windows are a red herring here. Drive letter names are not the best representation of a file system structure which has multiple roots. They are a strawman implementation of such a system.

A properly implemented filesystem that supports multiple roots would allow arbitrary naming for the volumes, like dvdrom:/path/to/file.avi. Such as system would get rid of the laughable user interface issues that plague Windows. For instance, if you plug in a device such as a camera, the Windows Explorer UI makes you believe that there is a device called Camera (or whatever), and that you have a path like \Camera\DCIM\.... However, if you cut and paste the textual version of this path, it doesn't actually work. IN a properly implemented system with multiple roots, it would be fine: there would be a camera:\DCIM\... path that is recognized uniformly at every level in the system. Moreover, if you ported over an old hard drive from an OLD PC, you would not be stuck with some drive letter name like F:, but rather you would be able to name it whatever you want, like old-disk:.

So, if Unix did have multiple roots in the filesystem structure, it would be done sanely like this, and not like in MS-DOS and Windows with one-letter drive names. In other words, let us only compare the Unix scheme to a good multi-root design.

So, why doesn't Unix have a sane multiple-roots implementation, in favor of sane one-root implementation? It's probably just for simplicity. Mount points provide all the functionality of being able to access volumes via names. There is no need to extend the namespace with an additional prefix syntax.

Mathematically speaking, any disjoint tree graph ("forest") can be joined by adding a root node and making the disjoint pieces its children.

Moreover, it is more flexible that the volumes do not have to be at the root level. Since there is no special syntax which denotes volume (it is just a path component), mount points can be anywhere. If you bring in three old disks to your machine, you can have them as /old-disk/one, /old-disk/two, etc. You can organize disks however you want, the way you organize files and directories.

Mount points are a good idea, which is why Windows has had them since around Windows 2000.

Volume mount points are robust against system changes that occur when devices are added or removed from a computer. Microsoft Technet

Note that the drive letter names from MS-DOS which persist into modern Windows are a red herring here. Drive letter names are not the best representation of a file system structure which has multiple roots. They are a strawman implementation of such a system.

A properly implemented filesystem that supports multiple roots would allow arbitrary naming for the volumes, like dvdrom:/path/to/file.avi. Such as system would get rid of the laughable user interface issues that plague Windows. For instance, if you plug in a device such as a camera, the Windows Explorer UI makes you believe that there is a device called Camera (or whatever), and that you have a path like \Camera\DCIM\.... However, if you cut and paste the textual version of this path, it doesn't actually work. IN a properly implemented system with multiple roots, it would be fine: there would be a camera:\DCIM\... path that is recognized uniformly at every level in the system. Moreover, if you ported over an old hard drive from an OLD PC, you would not be stuck with some drive letter name like F:, but rather you would be able to name it whatever you want, like old-disk:.

So, if Unix did have multiple roots in the filesystem structure, it would be done sanely like this, and not like in MS-DOS and Windows with one-letter drive names. In other words, let us only compare the Unix scheme to a good multi-root design.

So, why doesn't Unix have a sane multiple-roots implementation, in favor of sane one-root implementation? It's probably just for simplicity. Mount points provide all the functionality of being able to access volumes via names. There is no need to extend the namespace with an additional prefix syntax.

Mathematically speaking, any disjoint tree graph ("forest") can be joined by adding a root node and making the disjoint pieces its children.

Moreover, it is more flexible that the volumes do not have to be at the root level. Since there is no special syntax which denotes volume (it is just a path component), mount points can be anywhere. If you bring in three old disks to your machine, you can have them as /old-disk/one, /old-disk/two, etc. You can organize disks however you want, the way you organize files and directories.

Applications can be written which depend on paths, and the validity of paths can be maintained when the storage devices are reconfigured. For instance, applications can use well-known paths like /var/log and /var/lib. It's up to you whether /var/log and /var/lib are on the same disk volume or on separate ones. You can migrate a system to a new storage topology, while preserving the paths.

Mount points are a good idea, which is why Windows has had them since around Windows 2000.

Volume mount points are robust against system changes that occur when devices are added or removed from a computer. Microsoft Technet