Confirming points about [in~] signals+floats...

Hi all,
Just want to just clarify my understanding, as well as see if there are suggestions for better approaches than the ones I present here:

1. In order to use an abstraction with [poly~], all in/outlets will now *also* need [in]/[out] objects. So in making an abstraction, if there is a chance at all it might end up being used with [poly~] (and who can tell?), they'll need to be added (now or later).

2. [Poly~]'s can be nested reliably-- So my [poly~] subpatch can contain another [poly~] object + patch.

3. [send~/receive~] is a reasonable way around the problem of needing to send different signals to different instances. For example, to load 4 instances of a delay patch in [poly~] and send them all different signals to control delay time.

4. Along those lines, I'm having problems when signals and floats need to get along together. For example, in using a delay patch, one might drive the [tapout~] time from either a float or signal. But as long as the signal is connected (even if you want to use the float at the time), it will output a stream of 0.00. Is this where I'm supposed to use the polyphony management parts of [poly~] I haven't looked at yet, as efficiency has not been the most pressing problem?

Confirmations & suggestions?

Thanks,
Brian