Nah, you misunderstand me. I don't care about changes to opening or manipulating file contents, this is all about the metadata associated with the file.
File types should form a hierarchy, so, eg ogg is subtype of music is a subtype of media is a subtype of file. And then the attributes a file carries is defined by the filetype, with inheritance. So, eg all files have a size, and then all media files have a length, and all ogg files have channel count, for example. This tends to keep the interfaces simpler, because it means you don't have to present the user with 7843264372 different attributes to constrain, it's very likely they know the file type they're expecting and so you obviously only offer the attributes that are defined for those file types.
Myself and a few friends actually implemented all this a few years ago, basically building the UI and everything on top of Postgresql. It worked tremendously well and was fantastically powerful. However, the issue, as it will always be, is making a sane bridge between such a rich and powerful system back to a normal file/directory system such that the command line works. We never really implemented it, though did have some ideas. As an indication of how powerful it all was, we never bothered adding "name" or "directory" attributes, which would, logically have been attached to the root file type. The meta data was so rich that you really didn't need to name files at all. I guess the obvious take away here is the age old adage of "a system is only as good as the data that's in it". In this case, it was excellent, but it could quickly deteriorate.