COM objects and LUA
Believe it or not, you can develop, register and use COM objects with an LUA account [1]. COM objects are typically registered at one of one of two places.
HKLM\Software\Classes
HKCU\Software\Classes
Some people think that COM objects are registered under HKEY_CLASSES_ROOT (HKCR). This is partially true. HKCR is not a true registry key in the same way as HKEY_CURRENT_USER (HKCU) and HKEY_LOCAL_MACHINE (HKLM). Instead it is a hybrid key that merges the two keys above giving precedence to the information stored in HKCU. So whenever you open HKCR you are really opening a comibined view of the machine default COM settings and the user COM settings. This combined view will give precedence to user settings. This means that when you create an object with CoCreateInstance() or similar APIs, COM will use an object defined in HKCU, before HKLM.
But wait! ATL generated scripts all write their information to HKCR, how does that work? When you create a new key or value under HKCR, it will default to creating this key under HKLM. Unless the key already exists under HKCU. In that case the information will be stored in its existing location under HKCU. This means that you can develop, register and use COM applications all as an LUA. You can update most RGS files it ATL projects and force them to register under HKCU\Software\Classes instead of HKCR.
The is really only one small gotcha to this but it typically only affects services. HKCR will merge HKLM and HKCU. When you are impersonating a user, say in a service, HKCU will still be the settings for the server process and not the impersonated user. This means that users will not be able to override the default behavior when creating COM objects in this manner [2].
Couple of links on the issue
[1] I know it sounds a bit redundant to say LUA account when LUA stands for limited user account. So what I am really saying is limited user account account. But it just sounds weird to say "with an LUA".
[2] Depending on who the user is, that could be a good thing :)