For a basic 60-years-old John Doe use, since the beginnings of his digital life 20 years ago, facing files' names+extensions and formats has been becoming closer and closer to nightmare : <div> The numbers of formats used by average Joe rocketed through the roof : multimedia files as movies are common now, lots of new formats for the same task (ex: PNG, SVG for images, GIF and JPEG are still common), etc. Two examples of concrete and common nightmares : Dear Joe, you used to listen to mp3 files ? Now, there's better formats. mp3++ = mp4 ? Actually this time, it's for video, the sound one is m4a, but the files are commonly referred to the format name : AAC. Headaches ? Wait, there's WMA, Real Audio, Ogg/Vorbis (don't confuse with Ogg/theora), … Dear Joe, you foolishly thought you could play this .avi as the previous one ? But the required codecs are different ! Exactly, it's a set of formats, not just one, and only the container is publicized by the extensions. Headaches again ? Fact is, nowadays, extensions are a true miserable failure : it's scarcely helpful for the end-user to foresee if he could read or not the files, it's overloading the file's name, and a lot more. Yet, how to handle the issue (allegedly) tackled by extension a more elegant way? Fortunately, lots of uncoordinated improvements already show us useful clues : First : MIME-Type in the meta-data and libmagic to clean up after files made or send by low-quality way. I'm not skilled enough, but some competitors' ideas are deemed even more efficient [1] according to some smart people. Second : Icon's preview [2] ! If the end-user gets a preview right in the icon, he knows *without technical computer skills*, the icon's file is supported, dead-brain simple way. Know issues : We need to be able to send files through legacy files systems as in a FAT USB-key. We also need to keep compatibility with command lines as   rm -f a/path/*.wma We truly need to extend preview system to all formats. A competitor anticipated in a wonderful way this intention [3], as cover flow effect, to browse a list of images or movies. To keep compatibility with FAT files systems, why not just keep the extension and hide it at least in the graphical interface ? It also keep compatibility with all command lines. Further more, for the terminal, why not a system asking for meta-data, instead of extension. For example :   rm -f a/path/*#wma   where # means "with 'following' as meta-data. Another smart guy evoked the idea, and indeed, it sounds great in my unskilled ear :   cp a/path/~*#sound,jazz path/to/backup   and all the jazz music of the folder is saved, not the jazz images, not..., only what he desired. Dirty extension are even less necessary. Yet, some issues remains : if a addressee can't read a file, the sender has to know the file format. That's why we would likely still bother the end-users with formats when creating a files, or when an error occurred, reading them. But only formats names are required, not extensions, first gain. Then, instead of just prompting an error, we could first ask him to install format support : reducing the actually problematic formats number. We could extend the user experience in a very consistent way : same management of restricted files/folders, of remote/unmounted folders, for files' protocol instead of just format, as a bittorent file, ... </div> It likely would be better for the preview to be built by the file default application/engine, in order to ensure opening the file opening is actually going to work. The system is also scalable : if the (standardized) meta-data is the icon key to build the preview, let's imagine, for example, one kind of spectrogram-based sound preview for alternative music, another for jazz music, another for rock music, and so on, as we wish, according to the theme. We should care about preview explicitness : the preview of an editable ODT should differ from an (almost) only printable PDF, by instance. Links : [1] <a href="http://developer.apple.com/documentation/Carbon/Conceptual/understanding_utis/understand_utis_intro/chapter_1_section_1.html#//apple_ref/doc/uid/TP40001319-CH201-DontLinkElementID_15" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://developer.apple.com/documentation/Carbon/Conceptual/understanding_utis/understand_utis_intro/chapter_1_section_1.html#//apple_ref/doc/uid/TP40001319-CH201-DontLinkElementID_15</a> [2] <a href="http://media.arstechnica.com/articles/columns/linux/linux-20060905.media/icon_theme.jpg" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"></a> <a href="http://docs.sun.com/source/817-5309/images/naut_viewpane_text_window.tiff.gif" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://docs.sun.com/source/817-5309/images/naut_viewpane_text_window.tiff.gif </a> *by the way, notice the file double-extension, very user-friendly indeed*<a href="http://developer.apple.com/documentation/Carbon/Conceptual/understanding_utis/understand_utis_intro/chapter_1_section_1.html#//apple_ref/doc/uid/TP40001319-CH201-DontLinkElementID_15" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> </a> [3] <a href="http://www.apple.com/macosx/leopard/features/finder.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://www.apple.com/macosx/leopard/features/finder.html</a> & <a href="http://www.apple.com/macosx/leopard/features/quicklook.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.apple.com/macosx/leopard/features/quicklook.html </a>