oh yes, I forgot about those 
they solve a situation that can be originated if the amount of items to be partitioned is bigger than the sum of Sizes
to better explain, partition Size “S” can be considered like a Pattern… it will be -even partially- repeated if you have enough items to partition
for instance, these produce the very same result:
in the earlier definition, when those grouped components you found were not present, if you wanted n partitions you could specify n-1 percentages using Gene Pool, and the last one was not even calculated because I assumed all that was left was thrown in the n_th container, which it does, but only if the remaining items are less than the amount of the very first partition
if they are more, then the Size list restarts 
for instance, on 100 elements I use partition [10,20,15,25] assuming the 30 remaining ones will be thrown in a last branch with 30 elements, but because 30 is bigger than the first amount in Size list, then the Size list just restarts like a pattern and I get 10 and 20 instead of 30
the group you refer to just inserts as last value of Size list the total amount of remaining items, in such a way the sum of all the Partition Sizes is always equal to the total number of items to be partitioned
in A we have the n-1 partition sizes, which are summed together in B, then we find how many should be in the n_th container by difference from the total item count and B, then we insert that value at the end of the Size list with D