GoboLinux is a distribution which sports a different file system structure than 'ordinary' Linux distributions. In order to remain compatible with the Filesystem Hierarchy Standard, symbolic links are used to map the GoboLinux tree to standard UNIX directories. A post in the GoboLinux forums suggested that it might be better to turn the concept around: retain the FHS, and then use symbolic links to map the GoboLinux tree on top of it. This sparked some interesting discussion. Read on for more details.

It appears to be slick, but in fact, OS X is just as messy as everyone else. The only difference is that OS X creates some fancy directories such as /Applications, and then includes a text file that tells graphical applications to ignore the default FHS. but make no mistake - it's still there, and it is still as messy and unclear.

Again a case of band-aid. It doesn't actually solve the problem, it just hides it. You know, flipping over the picture of your wife.

basically it straps a whole new ecosystem on top of a BSD kernel and basic tools.

so ones your past the kernel startup your in a whole different world.

These days it seems that many promising approaches to building a new computing environment in the short-to-middle term do not try reimplement everything down to the metal, but instead they use, say, Linux, as a "driver" and then build the environment on top. The advantage is that you can instantly leverage all the Linux drivers, be it FOSS or proprietary, while treating the underlying Unix-like system as a black box, as if it were part of the hardware. A nice example of this approach is the Etoile project. This is an excerpt from their site:

What is CoreObject? Basically, it's a replacement for a filesystem as a programmer and user interface. Files (in the UNIX sense of the word) never were a good abstraction; an untyped series of bytes is no use to anyone. The operating system needs to deal with things like this, but programmers shouldn't have to.

We already have a much nicer abstraction than a file; the object. Unlike files, objects have all of the structure and introspection that we want in order to be able to interact with them programatically. In Etoile, we want to treat everything as an object, and objects as first-class citizens.

When reading this one may think that such a radical departure from the main abstraction of most operating systems means to rebuild everything from scratch. An awful lot of work and no substitute for binary-only drivers. But in fact Etoile is a set of frameworks on top of GNUStep. Files are not eliminated, they are just pushed down in the abstraction hierarchy, so that they become as irrelevant, as transparent, to application programmers as registers and assembler instruction sets are. The crucial point here is that the underlying files are not just hidden from regular users, they are hidden from *everyone*; they are just a convenient backend. That's what makes an abstraction work.

kde is doing the same with their abstractions to exist on top of anything from linux to windows.

KDE4 looks nice. Still, there's the problem that it intends to coexist with other systems that manipulate files in different ways. Think of what happens when you boot from another distro (without KDE) and edit (create, rename, delete) your personal files from there, obviously without the corresponding updates in the Nepomuk database. Of course you could also mess up the CoreObject files of Etoile from another OS (the underlying problem is, I think, computer hardware is not really designed for safe coexistence of different operating systems, otherwise the BIOS would protect the different abstractions ) , but Etoile makes it clear that it's not designed to interoperate in that way.