This is required to allow user-installed components to augment or override the list generated from the system registry.

Chris certainly meant to take this one too. I'm sure of it.

dp is no longer @netscape.com. reassigning qa contact to default for this component

I believe the current thinking is not to load multiple registries. But rather, to build a single registy per for an app that may refer to components in multiple directories. Registry merging is not part of the picture.

Sounds like you're describing multiple system-component directories. While that would certainly be useful, it doesn't really address the same problem as this bug. How would a non-admin user add a component to such a system?

Some components may reside in areas not accessible to the user, but the registry read and written by autoregistration would have to move to a user-writable area. There should be a specified search path to autoregister all components in a single registry from multiple sources including user-accessible and system directories. The first autoregistration might copy a prebuilt registry from a system directory before autoregistering any differences. Either there is always a user-accessible directory within the search path where user installs can be done, or the user may be permitted to add to the path along which autoregistration occurs. The user installs a component either by dropping a component in a user-accessible dir that is already part of the search path or by adding to the search path, and then causing autoregistration to be executed.

Confirming topembed- per EDT triage [Note from dougt -- "...outside the scope of the GRE as I understand it."].