In general, no, since registering the assembly with COM+ registers it for
COM interop as well, and that's a limitation there. Your only choice in that
case would be to use aliasing, as you mention, but keep in mind it is only
available in WinServer 2003 (it can be done via de Component Services
console, though, you don't need to use the API if you don't want to).

Depending on your exact needs I might be tempted to solve this via code
generation, maybe. For example, I could put all meaningful code inside a
regular .NET assembly deployed to the GAC that is not used in COM+ at all.
That would contain all the necessary logic.

Then, I'd create a "fake" component to register in COM+ which would be a
simple class (or set of classes) that act as facades over the underlying
common library by simply forwarding the calls in it to the real
implementation classes. Since this is very simple, I could, in fact,
generate this by using a simple script (maybe even a codesmith template or a
simple script using CodeDom and templates) that takes a new
Application/Class name, generates the code for the class, and compiles the
assembly.

Having that, if I needed to support a new array, I'd just run the script
with a new name and register the generated assembly into its new COM+
application. SInce all the underlying logic is abstracted away in a single
assembly, if changes are needed I can just fix that and redeploy to the
machine's GAC.