Thanks IOhannes for all your comments and suggestions.
I just realized that there are several ways in which identical symbols for different function definitions could cause a problem and I did not distinguish them.
1. Pd looks for a setup symbol when trying to load an external binary. 2. A loaded external calls an exported function in Pd. 3. Pd calls an exported function in Pd
Case 2. and 3. can only lead to symbol collision when a single precision and double precision Pd are running simultaneously. So far, I have not seen symbol collision happen though I've often ran them simultaneously. I understand that theoretically it's not guaranteed that it won't happen, that's also the reason why it is generally recommended to only export truly global symbols. However I think it is not really a concern, as there is normally no reason to run single and double precision Pd together, apart from testing purposes.
For case 1., protection is needed indeed. As IOhannes' list of possible approaches indicates, it's not a trivial intervention. I've also been thinking of a mechanism where Pd 'probes' a class at load time in order to find it's float type before instantiating any object. Rather it creates a private test instance for that purpose and tries to solicit output and check the size. To program this is not trivial either, if possible at all, but the advantage would be that it does not have consequence for class code.
Actually I think we have time to find and implement a solution because during the double precision development and test period we do not depend on it. If only we find a good way to point different Pd installations to subdirs in their own 'extra' for loading externals. What I meant to say in my previous mail is, that external executables like bonk~ are found from the proper location because Pd apparently knows they are in it's own extra dir, wherever the installation may be located. I do not know where this path is set but we need an option to add more dirs to that local path without using preferences.
Katja