You just have to be 100% cognizant of the references that Cores* have to each other. Thinking in a modular way, where those each Core is a black box unto itself, with no dependencies on the others is the ideal. Only purely informational messages would be passed between them.
However, to really get things done, Cores need to collaborate and often in a more intimate way. They sometimes need to share bits of themselves with each other.
For instance, a module might create a UIComponent that it will 'export' a reference via pipe message to the shell, or main app, which holds the primary display hierarchy of the clent. The shell will insert this component into its view hierarchy and the user will be able to interact with it. However, before exporting that UIComponent, the module instantiates a Mediator that also has a reference to that UIComponent. So the module is 'mediating' interactions with that view component, even though the shell places a reference to it in its display hierarchy (the main application).
In view-sharing this setup, there are a few important things to keep in mind:
1) The agreement between the module and the shell on the abstract class to be passed, in this case UIComponent. This allows the shell to treat the visual components from all modules the same, whether they are Panels, Datagrids, TileLists, etc.
2) The class is being is shared between the module and shell, here provided by the Flex framework, but in your own app perhaps by a common API library that you create.
3) There must be a coordinated handling by the cores sharing the reference when it comes to reference removal. Whichever core initiates the process must not only do its part but also alert the other one, so as to ensure both sides release all references.
Now to consider your question of the sharing of Proxies.
Imagine for the sake of discussion a Module that is written as a utility, which has a full set of classes and an entire PureMVC apparatus focused on creating and managing the Proxies necessary to talk to Flickr, and also implements a nice caching and undo capability. And instead of exporting view components, it exports Proxies. The Proxies it exports are well defined and actually packaged in a separate API.
If it were just that
all the Proxies were exported, then we'd just include the library and deal with it all ourselves, who needs to load a module just to be a simple Proxy factory?
But instead, we export simple proxies that manipulate the data references with an API we expose, and our module is actually an application that manages all the 'frob' authentication and other such stuff that makes developers say 'huh?'.
Send a configuration VO to the module by pipe message, and the module configures itself and awaits further instructions in the form of pipe messages. You may respond by authenticating, fetching datasets, cloning them, and letting the rest of the app have Proxies that interact with the cloned datasets (but don't do all the service interaction). You can expose methods to undo by replacing the dataset with the original, OR, write all the changes back by invoking a Proxy method, which sends a Notification that the module has a Command registered for which calls a RemoteProxy (that doesn't get exported) to the update service with the new data.
Without going much further than that, we can see that we'd be:
1) Sharing references to Proxies which are watched and manipulated in various external cores, but managed in one. We'd place these all in a library exposed to external module developers and used in the exporting module itself.
2) In the exporting module, we'd be in charge of things like instantiation and removal, exporting , caching, service interaction, data integrity logic.
3) In our external cores that are using the exported Proxies, we'd sometimes be listening for their update notifications when data changes, displaying their data and interacting with their methods.
4) All the same caveats as the sharing of view components apply in terms of coordinated teardown.
Hope this provides some perspective,
-=Cliff>
* When I say 'Core', I mean the app or the modules, each has a set of MVCF actors associated with it. When I say 'module' I mean... module. 
