Hello,
Since a few years I've been using Pd-extended 0.43 incidentally, and since a few months I use it intensively. The discontinuation of user-settable global search paths made me hopping around between alternative solutions, finding out their pro's and cons by (sometimes painful) experience. Don't get me wrong - I think the discontinuation of user-settable global search paths was a good decision. Once you get the best way to work around, it's much easier to share complex patches including dependencies.
Initially I preferred the 'namespaces approach'; organize abstractions in folders and instantiate them like you can instantiate objects as [cyclone/svf~], [zexy/limiter~] etc. Sometimes however I felt the need to reorganize folders with abstractions or homebrew externals. Such reorganization forces the namespaces in patches to be refactored. Not good!
Then I tried [import] and [declare] instead. I settled on [declare] because it is vanilla Pd, the most flexible approach for all sorts of situations. Fortunately, [declare] doesn't report an error if a path is non-existent, so you can give several options to cover various situations if so desired. I include my home brew binaries and abstractions in subdirs of a project dir, and point to them from the main project patch with [declare -path bin], [declare -path abstractions] and so on.
But ow!... with all the namespaces removed I suddenly recalled what makes namespaces so useful. Some classes exist in more than one library. A notable example is [pow~]. There's one in vanilla / Pd core and one in cyclone. Both used to have their exponent and mantissa inlets swapped as compared to [pow]. Somewhere in the Pd 0.43 series, vanilla's [pow~] was refactored to have it's inlets matching the [pow] format. So it became incompatible with Pd 0.42, while [cyclone/pow~] was still compatible with Pd 0.42 and 0.43.
Namespaces are also very useful if you have collections of abstractions which you never share but only use for development purposes. For example, I have collections of oscilloscope abstractions and small math utilities. They are stored in their appropriate subdirs on one of the default location as mentioned here:
http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files
So I can instantiate something like [scopes/scope2~] to quickly check two signal waveforms without including the path in the patch itself, and the object must be removed before the patch is shared.
After struggling with Pd search paths for many years, I'm finally starting to get a grip on it. Thanks to / forced by discontinuation of user-settable global paths. No matter how, I guess this will remain tough matter for Pd beginners.
Katja