Sorry, me again!
Illustrator plugins are simply dynamic shared libraries that are loaded at runtime into the Illustrator process address space. So, yes plugins can share code and data as they do when they interact with the SDK suites and document art. There is not a separate copy of the suites and document for each plugin.
I am not sure exactly what is going on with the shared libraries used by your plugins, some code might help. Are they dynamically or statically linked to your plugins? In general, if they are statically linked each plugin will get its own copy of the code/data, whereas if the shared library is dynamic, there will be only one copy of the code/data. But you say the plugin name comes from a #define, which is a preprocessor directive that will replace the symbol before compilation, so I don't see how this could change at runtime.
Oh good! You again! :-)
I'm using Hot Door's CORE which, as you know, is mostly a collection of wrappers for the Adobe suites, which I guess makes it sort of a hybrid static/dynamic. I define the name of the plugin using #define kPluginName "Yet Another Plugin" much as is done in the Adobe SDK samples, along with other globals but not in a namespace. I then have a preferences class which is created with the "new" constructor.
In the Preferences class, a string variable stores the path to the preferences file. A CORE function returns the path to the preferences folder where I append my preferences filename to the variable prefPath:
This has worked for months when the .cpp and .hpp files were with the rest of the plugins' source files. Since I moved the files to a common folder and added the files to the project as well as added the new folder to the user header search paths, I "clean" the project and launch it under the debugger. When I step through the code, I see the value of kPluginName is another installed plugin, not the one I just built. After putting std::cout statements in various places in this and other plugins, then running in debug mode without breakpoints, I found that things appear to function normally and in the proper order.
I guess for now I'll treat it as an Xcode anomaly and hope it doesn't come back later to bite.
I have had similar issues with XCode header search paths. Make sure it is pulling your included files from the correct location. It sounds like that could cause exactly the problems you're experiencing.
That makes perfect sense: drilling into another project's files could make a real mess. I checked my search paths and they look good. Thanks for the suggestion, though, it's a very good one!