In a patching perspective, [pd~] object works like a subpatch so there should not be any multi-threading or multi-instance issue. If you create a plugin, you should create the UI in the main patch and forward the relevant messages to the [pd~] object.

If you would like to distribute the plugin, you might want to install in a specific path the Pd binaries that will be used by the [pd~] object, this way you simply have to hardcode the [pd~] arguments with the installation path. But as suggested by IOhannes, you can also use the [pdcontrol] object to get the path of the patch and then keep the plugin library and the Pd binaries next to each other (this might require to generate dynamically the [pd~] object by scripting) , so you'll can simply distribute a self contained bundle.

At this time, using [pd~] to load externals seems to be the most convenient solution because, there is no need to compile another version of Camomile but most of all, the code of the externals doesn't require any adaptation for multi-instance and multi-threading (as PDINSTANCE might not be the only change to do - for instance, if a object uses a static global t_symbol that is not defined per thread).

At last, even if an object is compiled with the multi-threading and multi-instance support, it doesn't seem possible to simply ship the object library next to the patch, at least I never managed to do it because of some unresolved symbols that I think are due to way the DAWs load the plugin and export its internal symbols.