> Apple encodings describe what glyphs should be rendered. Not which unicodes they must have
Unfortunately, this is now how it works. Apple, Microsoft and others define "codepages" as a way to convert text from 8-bit encodings to Unicode and back. These codepages are deposited at the Unicode consortium: http://www.unicode.org/Public/MAPPINGS/VENDORS/
The MacOS Roman codepage as defined by Apple is used by operating systems and applications to convert between Unicode text and 8-bit MacOS Roman-encoded text. If you make a small text file in TextEdit that contains two characters: \u2126\u03A9 (given here with a backslash notation), save it as plain-text MacOS Roman-encoded, you'll get two characters: \BD\BD. But if you open that file again in TextEdit and save it as Unicode, you'll get a file that contains two Unicode characters: \u03A9\u03A9
This means that Apple holds a fallback mapping for MacOS Roman: \u2126 -> \BD and \u03A9 -> \BD, but the primary mapping is the second one, as it also works the other way: \BD (dec 189) always gets converted to \u03A9. Which is consistent with the MacOS Roman codepage definition deposited at Unicode.org.
With codepages, text mappings are of primary importance. Therefore, the same mappings should be used in fonts and font-related tools. In case of OpenType and TrueType fonts, new Mac OS X applications as well as Unicode-based Windows applications use the cmap 3.1 mapping of Unicodes to glyphs. For text encoded in MacOS Roman to be displayed properly with a given font, Mac OS X will first convert the MacOS Roman code 0xBD to U+03A9, and then it will look up the font's cmap 3.1 table for the mapping of U+03A9 to a glyph. (Old Mac OS applications use the direct mapping from cmap 1.0 to glyphs, so in cmap 1.0, 0xBD should map to the same glyph).
In case of Type 1 fonts, Mac OS X will parse the glyph names and map those to Unicodes using an internal list, and the will display the glyph with the appropriate name. Also, in case of OpenType PS (.otf) and Type 1 fonts, Adobe Acrobat and other PDF parsers will retrieve the original Unicode codepoint by parsing the glyph name.
Theoretically, Mac OS X should do it by using the Adobe Glyph List (AGL) plus the "uniXXXX"/"uXXXX" glyph naming convention. However, in Mac OS X 10.6.8, it does not to seem be doing it. It does understand AGL but not the uniXXXX naming.
I've just tested a Mac Type 1 font which has two glyphs: one named "Omega", the other named "uni03A9". As one would expect, the "Omega" glyph was mapped to U+2126, so Apple implements the Adobe Glyph List mappings. But it seems that Mac OS X still does not understand the "uniXXXX" convention as the U+03A9 character is not displayed using the uni03A9 glyph. But at least Adobe InDesign does that correctly (and so does Adobe Acrobat).
I also tested another variant of this font which, instead of "uni03A9" uses "Omegagreek", which is the old AGL name. Then Mac OS X (TextEdit) will display the glyph. (Reminder: "Omega" is part of both Adobe Glyph List and Adobe Glyph List for New Fonts, "Omegagreek" is only part of Adobe Glyph List).
In any case, even though Mac OS X does not "understand" uni03A9, it will still map "Omega" to U+2126, not to U+03A9. This means that in any case, the mac_roman.enc should be changed.
The 189 mapping there should point to the glyph for which the Unicode is U+03A9. The new name for that glyph is "uni03A9". The old name for that glyph is "Omegagreek". Mac OS X will not understand the new name, only the old name.
For that reason, I believe that we'll need to do some more changes: produce an branch of encodings ("obsolete") which are strictly compatible with AGL (the old naming), and change the "proper" branch of encodings which are compatible with the new naming.