When you click on a file and choose Open With, but you don't choose Change All, your compute makes a special hidden list buried deep in the secret recesses of Mac OS X. This hidden list is consulted when you double-click a file. It will look at the list and say "Is the file that was just double-clicked on in this list?" If the answer is 'yes' it will open it with the program you specify. If the answer is 'no' it will open it with the default program for that app.[1]
So let's say you have a file called MyInformation.odt. Normally, ODT files open with Text Edit. You change MyInformation.odt to open with NeoOffice. The Mac makes a list, and on that list it says "MyInformation.odt opens with NeoOffice."
All good, so far. Now you make an alias to the file.
But now it gets sneaky. Now you have a new file, that's called "MyInformation.odt alias". You double-click on that. The Mac finds the reference to "MyInformation.odt" and goes to look up what program to use.
It consults its secret list. The list has "MyInformation.odt" on it...but it does not have "MyInformation.odt alias" on it! So it doesn't "count" as being in the list, and the Mac uses Text Edit to open the file.
What????
That's completely wrong. There is no secret list. When you Get Info→Open with: and
do not click on "Change All...", Finder adds a 'usro'(0) resource to the document's resource fork, creating the resource fork if necessary. The content of a 'usro' resource is what's called an "Alias Record", which is what an "alias" really is. In this case, the Alias Record points to the application you just selected.
I've just been looking at the Apple tech information on their developer site, and it appears that my information is outdated. If I'm reading it correctly, what you say is correct for OS X 10.2.0 and later; prior to that, exceptions were stored in the Launch Services database. (I haven't looked at the Launch Services documentation in a long time.
It also appears, as an interesting quirk, that the usro(0) resource
does not contain an alias record. Instead, it contains four bytes indicating the length of the resource, followed by a hard-coded path to the application that's been chosen. This means, among other things, that if the path to the application changes (if the application is moved or renamed, for example), the new setting for "Open With" will fail. It also means that if you copy a file containing a usro resource from a PPC Mac to an Intel Mac or vice versa, the mapping will fail, because there is no provision for storing the endian value of the four-byte path length indicator. PPC Macs expect it to be big endian; Intel Macs expect it to be little endian. (I have an PPC and an Intel Mac but I haven't tested this.)
I repeat: it makes absolutely no difference whether you double-click on a document or an an alias file that points to the document. In fact, a not infrequent plaint among beginning programmers, especially beginning AppleScripters, is that there is no way for the application to learn whether an Alias File was involved, let alone which one.
That might be true in Applescript. I don't know; I don't use AppleScript. It is not true in Xcode and in other programming languages. In these environments, Open and Drag events will contain a reference to the alias if an alias file is used to open a file (or an alias is dragged to the application). It is the programmer's responsibility to resolve the alias using FSResolveAliasFile or FSResolveAliasFileWithMountFlags in Carbon. It's a bit trickier in Cocoa; you start with an NSString that contains the alias record, and you have to massage it to an fsRef, resolve the fsRef using FSResolveAliasFile, and turn the result back into an NSString using CFURLCreateFromFSRef or HSURLCreateFromFSRef. The upshot is that, yes, a program can tell if it was opened from an alias or an actual file.
