Unfortunately, the necessity to distinct between files (and lack of filesystem-level transactions) and directories led to inability to have a lot of fancy filesystems. There are tons of research papers and projects, which just cannot be implemented on GNU/Linux in non-kludgy way.
For example, there would be no need in archivers (like tar), when you could do `cp ./directory archive.tar` (OS X has something similar this with dmg HFS images). Or you could have `/etc/foo.config` as a text file, but also access separate options as `/etc/foo.config/section/option`. Or you could have versioning built-in into a filesystem. `./foo.txt` is a current version, `./foo.txt/history/` is a directory with a list of revisions, and `./foo.txt/history/2010-01-23T16:24:00Z.001` is an old version snapshot.
While I was writting the comment above I was mostly thinking of Plan 9 and GNU Hurd. Couldn't quickly remember exact names, but you should look in direction of those two OSes. They were made to address the shortcomings in UNIX design, and had some fancy concepts.
You can implement most of those ideas with FUSE filesystems. The archiver is a simple one (keep file tree, compress on unmount). Yor config file is another (albeit the wisdom of imposing a config file structure from the file system reminds me of the Windows registry.
I am using the snapshot feature in BtrFS for 6 months now. Love it.
No, I can't. FUSE - as everything relying on kernel VFS switch - forces me to explicitly distinct between files and directories.
Look at the current state of FUSE-based archiver filesystems. They use kludges like file ./archive.tar.gz but (AVFS example) directory ./archive.tar.gz#/file.txt to get around this limitation.
As for Windows Registry - it is not an absolute evil, it's just that Windows implementation of the idea of a centralized tree-like key-value configuration storage is unbelievably crappy. For example, there're (Plan 9-inspired) /proc and /sys, and they feel perfectly fine.
I remember back on my Amiga pretty much anything could be represented as a filesystem.
This lead to lots of weird things being implemented (like a reboot-persistent ram-drive), but one of the things I remember distinctly is the tar-example you mentioned (except it was lzh/lha). You would literally do cd myArchive.lha and that was it. This was a legitimate file-system path where you could do whatever you wanted. Operations may have been slow on bigger archives, but you could treat it as just another directory. It was very neat.
I've always missed having that feature in sub-sequent OSes I've used and I'm very disappointed it's been 10 years and seemingly the best we have these days is Windows Explorer's Zip-support.
The Xbox Media Center has supported transparent access to multiple archival formats with a variety of compressions (including transparently folding multi-file archives into one file) for years. It's an illusion implemented in user space and not a part of the operating system itself, but in practice there's no difference to the user.
Except for a problem, that you have to mount (by accessing) GVFS-filesystem first. If you're using Nautilus to navigate to the file and start vim — it's fine, but it won't work for any non-GIO file browsing (bash, mc, emacs-dired, gmplayer, ...)
For example, there would be no need in archivers (like tar), when you could do `cp ./directory archive.tar` (OS X has something similar this with dmg HFS images). Or you could have `/etc/foo.config` as a text file, but also access separate options as `/etc/foo.config/section/option`. Or you could have versioning built-in into a filesystem. `./foo.txt` is a current version, `./foo.txt/history/` is a directory with a list of revisions, and `./foo.txt/history/2010-01-23T16:24:00Z.001` is an old version snapshot.