Well, you could just use the same name (internal unique name) for the toolbox in every plugin. Looking at the SDK, it's odd, but while you can iterate toolboxes, you can't ask for information about a given toolbox, which is strange. You'd have to try it, but it might be that if you ask to create at toolbox with a name that's already in use, it might just return you the handle of that toolbox. Or it might give you an error, which wouldn't be much help
Note that at a certain point (CC2015.3 I think?) the user can create their own toolboxes and move tools around, so it may be that the best you can do is give a default starting toolbox for a tool.
That's pretty much what I'd hoped to do, except my interpretation of the function to give a toolbox a name when creating it was that the name had to be the unique identifier of the plugin, which would explain why there's no function to get the name of a toolbox.
I'd wondered about the practicality of storing the first AIToolHandle (or AiToolboxHandle) used in a small file. At startup, each plugin would look for the file, read it if they find it, create it if they don't, then come back at post-startup and delete it if it's still there. Of course, I need a way to test the handle in case it's leftover from a previous crash during startup.
Does that sound practical? :-/
Handles aren't persistent between sessions, so I'm not sure that's a great idea. Still, broadcasting the handle isn't a bad one.
You could have all plugins attempt to create the toolbox, and if they succeed, they could send out a notifier with the toolbox handle as a parameter. You can define your own notifiers (e.g. "MyPlugin_toolbox_notifier") and since you have to request to listen for it, only you would ever catch it. A plugin could catch the notifier and stash the handle, and when it's their turn to make the tool, if it's not null, use that instead of attempting to create the toolbox.
This is all assuming that asking for a toolbox named "something" when one with the name "something" already exists doesn't just have it return the handle to that toolbox. It's worth testing first; if you get an error when it already exists, then try the notifier system.
I thought deleting the "handle" file at post-startup would solve the inter-session discrepancy, but checking the age of the file before trusting it might be a sufficient backup check in case of a crash between its creation at startup and deletion at post-startup.
I'm writing the plugin using CORE, which includes a class that handles inter-plugin communication in much the way you describe. I'd hoped for something simpler that I could write once in a class, then simply include or subclass in one neat package because of the number of separate tool-type plugins I have in the works.
I'd hoped there might be a way for third-party plugins to use a built-in tool group trick, but at least the shared toolbox is doable, one way or another.
Thank you for your thoughts and observations!