I think that the current set of filesystem ops is a nice base. The "everything is a sequence of bytes" actually works very well given the access methods on a lo

I think that the current set of filesystem ops is a nice base. The "everything is a sequence of bytes" actually works very well given the access methods on a low level. However I think there are two separate things that need some serious addressing. First is lack of metadata intrinsic to the system. A lot of filesystems have such capability, but there are no standard APIs to access it. I think that if a standards body (cough POSIX cough) were to distill out a minimum set of searchable metadata functionality, a lot of fun could arise. The other part is the file metaphor itself. This leads to a lot of focus on moving, and putting, and copying. There is a largely under-utilized bit -- linking. We tend to associate filesystem trees with their paper counterparts, hence the above focus. However, with ln, you can create multiple hierarchies for the same set of files, organizing them different ways. Similarly this doesn't allow for easy reasoning about things like unionfs. All that being said, I don't thing this calls for a removal of the stream of bytes notion of files, in the end, such a thing pretty necessary. A good api/file format on top of the stream of bytes solves the problem just as well.