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.
The 'usro' mechanism was actually introduced in MacOS System 7 (the same release of MacOS that introduced aliases).
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.)
For quite some time now, an Alias Record has been considered by Apple to be an opaque data structure. That is, they do not reveal any clues about the internal structure of one, expecting all users to treat an Alias Record as a blob of bytes of indeterminate structure. They've made use of this to change the internal formats of Alias Records many times since making them opaque. I say "formats", plural, because indeed they do not all have the same internal structure. (One change that has become known is that many Alias Records now contain what is essentially a symbolic link, along with whatever other information they may carry that allows the symbolic link to repair itself if broken. But just as symbolic links come in two flavors (absolute or relative, according as the first character is or is not a slash), Alias Records can come in many flavors.
The internal format of an Alias Record is not documented anywhere. (That's what it means to be "opaque".) But when I look at a 'usro' resource, what I see is a two-byte type field, equal to 0 and probably meaning "the simplest possible Alias Record format: it's just a symbolic link". Then a two-byte length field, giving the number of bytes in the UTF8 absolute path to the application, followed by a null byte that is not counted in the length. (The null byte reveals itself if you change the "open with" application to one with a shorter name; the UTF8-ness reveals itself if you select an application with a non-ASCII name.)
In short, who's to say this isn't one of the many valid formats for an Alias Record? It does share (and in spades) the ancient problem with forcing a document to open with a specific application: it wants to forever after open with that specific application, even if you have another later version of the app installed elsewhere. (It also shares the ancient advantage that you can force a document to open with a specific version of an application, even if you have a later version of it installed elsewhere.)
As for the endianness, don't worry about it. All resources are stored big-endian on disk. Any necessary byte-swapping is done on the fly by the Resource Manager, at least for any resource types whose format it knows. (I recall that there's a way to add new formats its list, but I don't recall the details. Most apps that do custom formats register their own byte-swapping routines.)
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).
I'll look into that. As I said, open ALWAYS gives you an alias of some sort. But I thought that alias could only point to an alias file if you got it from the open dialog, and set the flag indicating you did not want it to automatically resolve aliases.
Of course, for a drag and drop, what's passed on the pasteboard is whatever the source application wants to put there, and an application may need to be prepared for whatever it's given. But when it's Finder doing the passing, whether through drag and drop or double-click, what Finder passes has always already been resolved. Or so I've always understood.
