The scalar version expects to receive a kResult object and a slot filled with what, at runtime, could be an array, and produces the same kResult and a single value obtained by iterating over the array items.
In a block-enabled time-series scenario, whenever a kResult is requested the block-enabled pipeline is immediately stopped after the evaluation of the $match stage, so the new Unwind stage must request, as input, N slots holding the top-level components of the result object (as requested by the parent stage of the Unwind), plus 1 slot holding a block value representing the path navigation.
During the getNext call the content of the first N slots will be copied into a new (possibly RLE-encoded?) block value where the repetitions are indicated by the position info of the latter slot.

Example:

Time series objects:

{
time: 1:00
measure1: 100
measure2: 20
measure3: [1,2,3]
},{
time: 1:01
measure1: 101
measure2: 21
measure3: [4,5]
}
...

Blocks:

time: 1:00 | 1:01 | ... N items
measure1: 100 | 101 | ... N items
measure2: 20 | 21 | ... N items
measure3: 1 | 2 | 3 | 4 | 5 | ...  arrInfo: 1 | 0 | 0 | 1 | 0 | ... M items (with M >= N)

Output:

time: 1:00 | 1:00 | 1:00 | 1:01 | 1:01 | ... M items
measure1: 100 | 100 | 100 | 101 | 101 | ... M items
measure2: 20 | 20 | 20 | 21 | 21 | ... M items
measure3: 1 | 2 | 3 | 4 | 5 | ...  M items  (i.e. the input block with no arrInfo)
arrIndex: 0 | 1 | 2 | 0 | 1 | ... M items

If we create an RLE-encoded block, the first three items could become

time: 1:00 x 3 | 1:01 x 2 | ... M items
measure1: 100 x 3 | 101 x 2 | ... M items
measure2: 20 x 3 | 21 x 2 | ... M items

In case the measure3 has an arrInfo made of all 1s, the output slot accessor would just reference the original values.