Loading multiple copies of a DLL group into the same process

Background
I am maintaining a plugin for the application. I am using Visual C ++ 2003.

A plugin consists of several DLLs - there is a main DLL that the application loads using LoadLibrary, and there are several DLL programs that are used by the main DLL and each other.
Dependencies usually look like this:

• plugin.dll → utilA.dll, utilB.dll
• utilA.dll → utilB.dll
• utilB.dll → utilA.dll, utilC.dll

You get the picture.

Some of the dependencies between DLLs are load time and some execution time.

All DLL files are stored in the executable directory (not necessarily how it works now).

Problem
There's a new requirement - running multiple instances of a plugin in an application.
The application runs each plugin instance in its own thread, that is, each thread calls the functions exported by plugin.dll. However, the plugin code is nothing but thread safety - lots of global variables, etc.

Unfortunately, fixing all of this is currently not an option, so I need a way to load multiple (no more than 3) copies of DLL modules into the same process.

Option 1: A clear naming approach
Create 3 copies of each DLL file so that each file has a different name. e.g. plugin1.dll, plugin2.dll, plugin3.dll, utilA1.dll, utilA2.dll, utilA3.dll, utilB1.dll, etc. The application will load the plugin1.dll, plugin2.dll, and plugin3.dll files. The files will be located in the executable directory.

For each group of DLLs to know each other by name (which is why interdependencies work), the names must be known at compile time, which means that the DLLs must be compiled multiple times, each time with different output file names.

Not very difficult, but I would not want to have 3 copies of VS project files and would not want to compile the same files over and over.

Option 2: build assemblies approaching
Create 3 copies of DLL files, each group in its own directory and define each group as an assembly by placing an assembly manifest file in it, which lists the plugin DLL files.
Each DLL will have an application manifest pointing to the assembly so that the loader finds copies of the DLLs that are in the same directory. This manifest must be inlined to find it when the DLL is loaded using LoadLibrary. I will be using mt.exe from a later version of VS for the job as VS2003 does not have built-in support for embedding a manifest.

I've tried this approach with partial success - dependencies are encountered during DLL loading, but not when calling a DLL function that loads another DLL.
This appears to be the expected behavior according to this article - the DLL activation context is only used when the DLL is loaded, and then it is deactivated and the process activation context is used.

Edit: Works with ISOLATION_AWARE_ENABLED

as expected - loading a DLL in load mode uses the original activation context of the loaded DLL.

Questions
Are there other options? Any quick and dirty solution. :-)

Will ISOLATION_AWARE_ENABLED

VS2003 work? Edit: He does.

Comments will be appreciated.

Thanks!