Last time around, we looked at an application compatibility side-effect of User Account Control on Windows Vista: the potential impact on Mapped Network Drives when running elevated. Another side-effect that may affect application compatibility is the changes we have made around per-user COM registration.
Back in Windows NT 4.0, HKEY_CLASSES_ROOT was simply an alias of HKEY_LOCAL_MACHINESoftwareClasses. However, beginning with Windows 2000, HKEY_CLASSES_ROOT is a merged view of the data in HKEY_LOCAL_MACHINESoftwareClasses and HKEY_CURRENT_USERSoftwareClasses. Aaron Margosis discusses how to leverage this merged view (and the differences in permission) to resolve LUA bugs in his Technet article Problems of Privilege: Find and Fix LUA Bugs. You see, when we search for a COM registration, entries in the HKEY_CURRENT_USER hive take priority.
And it is exactly this property (fixing LUA bugs) that makes this load behavior dangerous if your process happens to be elevated. A standard user is able to write to these registry entries, which is why it can help applications to work. Because a standard user can write the configuration for a COM object, we don't want to open the door to an elevation of privilege attack. If we simply enforced the same rules for an elevated process, loading entries from the user hive first, then a process could easily write a new configuration for a commonly loaded COM object, point the configuration to arbitrary code, and have an elevated process pick up that arbitrary code, executing it with administrator privileges! Consequently, we block loading of COM registrations from the per-user registry hive if the process' integrity level is higher than medium. That means you won't pick up a per-user COM object if you are manifested as requireAdministrator, or if you have manually elevated the application (right click - Run as Administrator). It also means you won't pick up a per-user COM object if you are running as a member of the local Administrators group and you have disabled UAC for some reason.
So, if you are an application developer who is designing an application to run elevated, you should make sure that you drop your COM registrations in the per-machine hive (which creating a new key in HKCR will do by default) at install time, rather than relying on a per-user installation.