Consider for example the case with a FeatureMerger or a FeatureJoiner.
I have always been wondering how the groupBy is executed here. Is this on a single port (e.g. Requestor or Left) or across multiple ports. Especially in combination with the option 'Process when group changes'.
I made a small illustration workspace, with the merging application inspired on 'a hiccup' I came across today where I wanted to accumulate incoming attributes at a 2DGridAccumulator, but there is no default field/option for this (an idea on this was already created, see; https://community.safe.com/s/idea/0874Q000000TlLbQAK/detail).
To see differences in results, I changed the order of the features entering the supplier input port of the FeatureMerger, and for whether features should first route to the Requestor, or first to the Supplier port.
In the cases when the feature order going to the supplier is changed (case 1 and 2), I see that most features don't merge, but I don't understand why it is feature 9 and 10 that merge in case 10 (I would expect only feature 10), and why only feature 9 is merged in case 2 (if any, I would again expect only feature 10).
Curious to hear if others have some feedback/ideas on the general scope of this question.

Not really the desired results, so in this case using Group By Mode: Process At End would give the expected results.
The performance advantage is that as soon as a pair of groups are matched, they can be released from the transformer so less data is cached. But... notice how the red groups are separated and so the first group of red data does not get paired with the last group of red data. If you use Group By Mode: Process At End then all the reds will be grouped. So there is a difference in behaviour. In the above example: