unzip nodes behave like vector splits.
in the bin versions each output gets assigned a bin and the node repeats the bins until all outputs are filled with the equal amount of bins (input bins%output bins = 0)

so, if you have 2 bins but 3 output pins the node distributes the 2 existing ones (out 1 and 2), then repeats the 2 bins again (out 3 and 1) and needs to repeat it again (out 2 and 3) to have 2 bins at each output.

in case you are comparing it to the former decons node. this one was not entirely logic, since it was ‘swallowing’ surplus bins

I thought that using a spread as input bin size in unzip node would act as in linearspread: if one has three inputs and two spread counts, the first slice of spread count is repeated to spread the third slice of the input.

In the case of unzip node it happens what you described; but since all of the other spread nodes are like the linearspread and since that one can have a number of spread counts and a different number of inputs, as often happens to me, I found a bit tricky that, once has fed a linear spread with
||
input|spread count

7|9

2|3

0.354|
||
one must feed the unzip input bin size pin with
||
9

3

9
||
since the first slice is not repeated as usual.

I’ll dig more into this, and find the right perspective to look at this node.