Lots of thoughts here, but little time. Here are the salient points to me:
1. The best analogy to this in Pd is [soundfiler]. [soundfiler] stops the world in order to load the file, which routinely causes dropouts. This is a constant source of disappointment and frustration to students especially if they're coming from Max. But the point here is that [soundfiler] is a control object, and Pd guarantees deterministic behavior for control objects.
2. Max users are used to there being no dropouts with [coll], which tells me that it must not be deterministic in the fanout kind of way Ico mentioned (unless Max has a very different message passing structure that can process a message cascade over several dsp ticks in a deterministic way).
3. So the question, as with all things cyclone, is whether it should be more Pd-like or more Max-like. So far we've defaulted to more Max-like with documentation, in order to support Max users who come over to Pd. In this case I think more Max-like makes plenty of sense since there is the load termination bang outlet, but I would want the deviation from Pd-like control object behavior prominently documented (probably with a compare/contrast with [soundfiler]). Then, for other Pd users, we need an easy way to make it run in one DSP tick; all things considered I'd rather have a custom attribute for that than a special argument. Might be a pain for backwards compatibility, but I think less so than switching the inlets of [pow~] was when it became clear it was necessary.
Matt