I've been investigating "how should a modern windows c++ application register its file types" with Windows (see http://stackoverflow.com/questions/2828637/c-how-do-i-correctly-register-and-unregister-file-type-associations-for-our-ap).
And having combed through the various MSDN articles on the subject, the summary appears to be as follows:
The installer (elevated) should register the global ProgID HKLM\Software\Classes\my-app.my-doc[.version] (e.g. HKLM\Software\Classes\TextPad.text)
The installer also configures default associations for its document types (e.g. .myext) and points this to the aforementioned global ProgID in HKLM.
NOTE: a user interface should be provided here to allow the user to either accept all default associations, or to customize which associations should be set.
The application, running standard (unelevated), should provide a UI for allowing the current user to set their personal associations as is available in the installer, except that these associations are stored in HKCU\Software\Classes (per user, not per machine).
The UN-installer is then responsible for deleting all registered ProgIDs (but should leave the actual file associations alone, as Windows is smart enough to handle associations pointing to missing ProgIDs, and this is the specified desired behavior by MSDN).
So that schema sounds reasonable to me, except when I consider #4: How does an uninstaller, running elevated for a given user account, delete any per-user ProgIDs created in step #3 for other users?
As I understand things, even in elevated mode, an uninstaller cannot go into another user's registry hive and delete items? Or can it? Does it have to load each given user hive first? What are the rules here?
Thanks for any insight you might have to offer!
EDIT: See below for the solution (My question was founded in confusion)
