Here is the promised proposal. It is about persistent, abstraction-scoped class name resolution.
1. There is an internal class 'declare', instantiated in several forms. One form is [declare compatibility ...], another is [declare requirement ...], etc. Shortcuts may be provided for convenience.
2. Any [declare] object is automatically sorted up to the head of a glist.
3. An object [declare requirement library this that] checks if libraries 'this' and 'that' are already loaded. If they are not, an attempt is made, and any failure reported. This simple behaviour might be further extended with version checking and auto-downloading. When these features are supported, they might be applicable to other dependencies as well: sound files, abstractions, etc.
4. An object [declare compatibility this that] registers symbols 'this' and 'that' as a compatibility declaration, which is active for its containing patch and all subpatches.
5. For any class name N and constructor C, it is possible to specify, that if N is multiply defined, C is not to be called, unless a particular symbol or symbols are compatibility-declared for an object's containing patch. If an active declaration matches, C overrides other candidates. Which could be implemented by:
6. Setting a callback during class definition. The callback, stored in an extended t_methodentry structure, would take as arguments all active compatibility declarations concatenated, and it would return an index of the first required symbol found there, or -1 if nothing is found.
7. Pd keeping track of name clashes, and prior to creating an ambiguous object, invoking the callbacks of all candidates. The constructor with the lowest nonnegative return wins. If all returns are negative, a constructor with no callback set wins. Everything else is undefined.
Krzysztof