The fact that the upstream HN comment has to explain two identical-sounding options that do different things should help you see what's wrong with the current impl. Your steps don't work with the "Open With -> Options" context menu like they point out, but rather only with the "Get Info -> Open With" options. Not the best UX.
For example, I can imagine if there were instead two radio buttons in "Open With": "Always for this file", "Always for this extension". All in one place.
Doesn't work when Xcode is the default app. I use macdown for mathjax files for math.stackexchange.com, and I have to use "open with" to choose macdown every time.
In old days Mac OS files had two properties: file type and creator type. File type could be like "TEXT" and creator type was a unique code for the application that created it (they were registered at Apple, I believe). All this was purely internal, users never saw such things: Mac file names normally didn't have an "extension", it was just "1995 Report" or something.
As a result it behaved like that:
- When you opened a file, it opened in the program that created it.
- When there were no such program, you could still open it in another program that claimed to understand these files. I don't remember how it was implemented, I think there was a dialog asking if one would like to use another program with some choice (probably the first one that fit).
This was rather handy with formats like "Encapsulated Postscript" in desktop publishing: this format supported both vector and raster images, but one normally used different applications to manipulate them.
This stayed for some time after the move to Mac OS X, but now I believe these things are gone or not used at all.
The concept of file extensions on windows is equally unintuitive (why is the type 9f.file dictated by what comes after a dot). It's just a question of what you're used to.
File extensions are the de facto type indicator on all platforms, not just Windows. Even when the FS has some other way to specify the type (e.g. a separate MIME type metadata field), the extension still normally sets the default value for that.
This is orthogonal to all that, though. It's about the UX to associate an app with a file type, regardless of how that file type is determined.
GNU/Linux doesn't automatically choose which program to use for anything (you can't ./file.png like you can in Windows). In my experience file managers tend to use file extensions to choose which application to use, and that application might then use libmagic and ignore the file extension. (e.g. giving a PNG file the .JPG extension will make the file manager think it's a JPEG, and therefore open it with an image viewer, but the image viewer program will use headers to recognise it as a PNG)