Perhaps this is a silly question, but I think this could put to rest a lot of the frustration/confusion associated with having different versions of modules to handle volume collections vs. single volumes:

Why don't we enforce a standard that any module that can take a single input volume also be able to handle a volume collection?

If you think about it, having a single module that can handle both input types is much more elegant than having separate modules that can handle the special case of only one input volume. It also forces developers to release modules that can handle volume collections by default, instead of having to wait until somebody requests a special version for their use case for every module. I can't even count how many times I've had to play around with converting volume collections to slabs or 4D volumes and vice versa just to get around this incompatibility if it even can be circumvented at all. Often the only way to accomplish this is to split the collection using a RegEx volume chooser for each volume and have multiple copies of the same module sequence, which only works if you know a priori how many volumes are going to exist in the collection.

IMHO, it would save everyone a lot of time and hassle to simply set it up correctly from the outset as a design requirement, though I'm not sure how amenable everyone is to this sort of policy. It would reduce the confusion/clutter of having multiple algorithms which repeat functionality but with different input requirements.

An alternative, but far less elegant, solution would be to create an iterator module that can take a volume collection as input and "feed" each volume iteratively as output to whichever module it is attached to. It would have to branch out every subsequent step in that sequence, similar to the Volume Collection Source, which I imagine would be convoluted to implement.

Sure, do you know who wrote the N3 module?

I agree, this will definitely take some time since there are many modules that would have to be retrofit. In the meantime, I have one module (N3 correction) that is a high priority for our pipeline that I can't take a stab at since I don't believe it is released as open source. Shall I make a new tracker to specifically request an update to that module?

This is possible, but would take a substantial amount of work. We're a bit tied up with pressing engineering goals relating to getting better validation/testing infrastructure and higher throughput cluster processing working.

These are excellent questions. I can imagine if there are multiple volume input pins, for example the registration modules which take a source and target, then there are 3 general cases:
multiple sources to 1 target
1 source to multiple targets
multiple sources to multiple targets (same number in each collection, which includes 1 source and 1 target)

Basically you have to check if the input collections have different numbers of volumes. If they're both equal in number, then it is a one-to-one correspondence between them. If it's a multiple-to-one correspondence in either direction then treat it as such. The real problem is if there are, say, 3 sources and 2 targets. I would assume it means apply each of the 3 sources to each of the 2 targets since any other interpretation doesn't make sense. So I think a conditional at the beginning to check the number of volumes in each collection, and then a block of code for each to set up the correspondence mode before entering a for-each loop, should suffice.

I think that would be extensible to the other modules that take more than one input pin such as image calculators.

For modules that are currently written to strictly handle single volumes, I would have them perform the algorithm inside a for-each loop, and output a volume collection. The nice part is you can also set these up to handle parallel or multithreaded operation.

I can easily recommend this as standard practice, but what do we do for authors who write algorithms that process single volumes?

Do I transform a collection->vol link into a for-each loop? What if there are multiple volume inputs? Do I do for-each, for-each,... or just once through? What if the number of items in the entries to the different pins are different? How do I match them up?

Suggestions most welcome.