What I mean is that a sufficiently powerful tag system can be used to emulate a directory-based system. For example, with simply a means to view files without tags, you can recover a single-level directory system (à la CP/M) by merely tagging files with at most one tag.

If you also incorporate a notion of hierarchical tags (where for every tag X, there exists a set of tags Y which act as the conjunction of X and Y) and extend the above ability to allowing viewing files tagged with X but not tagged with any child tags of X, you can recover the familiar multi-level file system again by tagging files with at most one tag.

GMail almost gets this right, as it has a hierarchical tag system, but (AFAIK) it has no means for viewing e-mails tagged with a given tag but not any child tags.

Hmm.. True.. My first thought was well, i could say the reverse, but realized, our current implementation of directories and hierarchies are restrictive. in the sense of having multiple tags/directory names to a set of files(it can be argued, symlinks do the job well enough). The analogy, also brought to mind the choice to allow multiple inheritance or not. I guess the trade-offs are the same. Power to the user vs easier(but restricted ) for the user -- I don't mean the tag system per se, but the idea of having only one level of filesystem.

P.S: As far as my personal stance, it comes down to the type of use/nature of application/(perhaps more appropriately) amount of attention being spent. I don't want to have to descend hierarchies of filesystem(Even ones, i created/customized myself) to find my music. OTOH, I'll be pissed, if i have to search for my code files by tags/file contents.

I was about to point this out elsewhere in the thread where someone was saying that you can do anything you want with a hierarchical directory structure and hard links ...

This is equivalent to hierarchical tags (if you allow that an "untagged" file is equiv. to the root directory) but maybe less confusing.