I spoke with David King, a Volt contractor at Microsoft Product
Support.

He told me that this was a "known limitation of the compiler."  He
suggested the following work-arounds:

1. Modify the source components to avoid creating the problem in the
first place. This is the most robust, and recommended, solution. For
example, choose sufficiently unique names for public symbols, given
the preceding information. Creating .NET components that work well
when exposed to COM clients usually involves some compromises (e.g.
anticipating the flattening of namespaces).

2. Modify client usage of the resulting library.
   a) The C++ #import statement allows selective renaming of imported
symbols: #import "msrepro.dll" rename ("msrepro_Class1", "Class1")
   b) VB6 (and other) clients have no such option.

3. Forego automated wrapper (interop) generation and write your own
COM-callable wrapper library. VC++ 7.1 supports mixed
managed/unmanaged code that would allow you to directly use a .NET
library from within a ‘traditional' C++ COM library, which would then
expose it's own interface to bridge COM clients to the .NET DLL.

4. Modify the exported type library. The only way to do this is to
decompile the type library to IDL, modify it (e.g. rename symbols),
and recompile. tlbexp.exe, any text editor and midl.exe may be used to
perform each of these actions, respectively.

I'll probably go with #4.  I'll post back here if it doesn't work.