This implies that fluidsynth~ as an external is presumably a nested external library. As if it couldn't be ever considered as part of ELSE or any other library. I know there's been a 'fluid~' external at some point made available on its own, but fluidsynth~ is not fluid~, fluidsynth~ has a distinct design, and there's no reason or rule that it has to be made available on its own. 

The last update of ELSE carries [score] objects that I think are really useful to write scores. The fluidsynth~ addition will be great as a counterpart so people can write scores to be played by fluidsynth~ as well as other oscillators from ELSE.

I can see it could be nice/useful/desired to have it as a single external, but so would be many other externals from ELSE. For instance, else has many reverb objects and includes a reverb based on the gigverb algorythm (giga.rev~) as well as anoter based on the freeverb algorithm (free.rev~) - there are single externals in pd also based on both algorythms but the objects in ELSE are not exactly the same and have a different design. Imagine there weren't such objects made available as single externals, why should I make them available as single externals instead of as part of ELSE?

Anyway, deken is able to search for externals inside libraries, so people using deken and searching for fluidsynth~ will find ELSE, and if you have [declare -path else] in your patch you're telling people they should have ELSE... 

Now, when I say people could 'grab' from ELSE, i meant it in some cases where they would want to ship projects with prearranged and preinstalled dependencies/externals, so one could just include fluidsynth~ in some 'dependencies' folder and ship it.''

By the way, ceammc has a fluid~ object and it is part of the ceammce single binary pack, so if one just wanted fluid~ they have to include the whole ceammc pack with over 700 externals. I'm just saying I offer an advantage over that with my single binaries for each external.

 cheers