The idea that every filename must have an extension, and that the extension is the one and only way to determine what type of file it is, is an obsolete holdover from old OSes like CP/M and DOS. Trusting the extension to identify the file type has even enabled a class of scripting attacks in email attachments. On MacOS it has never been that way, because the resource fork stores the file type (although file extensions in OSX have meaning inconsistently sometimes, unlike in previous versions of MacOS... this is more of a regression than a feature). It would be possible to apply the same idea on other operating systems whose filesystems have a metadata capability.

On Linux, the proper way to identify a file is to use the magic database (like the "file" utility will do for you on the command line): that is, identify the file by its own content rather than its name. That is the most robust way of the three methods, because the resource fork can also have an incorrect file type. (There are some comments about that here http://www.asktog.com/Bughouse/bhMultipleOSs.html under "Visible File Extensions", although that's not the whole story.)

So in the light of that, we should perhaps eventually deprecate the idea of using the extension for file type filtering. For example in QFileDialog it would be better for applications to use setMimeTypeFilters instead of setNameFilters, and the implementation could use QMimeDatabase::mimeTypeForFile() to check which files match the filter. On OSX it could alternatively try to use the file type from the resource fork, as long as that remains in common use, so that users will normally have files with correct types there.