I realised today that there is a counter-intuitive difference between the way that Metanodes and Components handle multiple flow variable input ports.
It’s probably a scenario that isn’t that common, but if you ever need this functionality in a Component, you will find you hit a wall as I did.
I would therefore request a modification to the Component Input node, so that we can decide whether the flow variable flows should be Merged or kept separate within the Component.
This example will hopefully better describe and demonstrate the problem.
Here I have three demonstration flows. It is a contrived minimal example to demonstrate the issue.
The first is taking two variable flows.
Both flows contain a string variable called “message”. In the upper branch the message is “Hello”. In the lower branch the message is “World”. It performs a String Manipulation on each variable to make them upper case, then turns them into a table row and finally concatenates the rows to form.
For good measure, I also added a unique variable to each of the flow branches “top flow” and “bottom flow”
The concatenation generates the following output table:
Having built this “complex” 
workflow, I decide to turn it into a metanode to tidy things up. The second example shows the metanode version, and again it generates the required output as above.
Internally the metanode is just like the original flow:
Now, being the type of person who thinks that this may have application elsewhere, I decide to turn the metanode into a component.
In the component’s Component Input node, I instruct it to allow in all variables, and internally, the component looks very similar to the metanode.
So similar, that you would probably expect them to behave the same way.
However there is a behavioural difference. The resultant output from the component is still 2 one-row data tables, but when concatenated it forms:
This comes about because the Component Input node currently acts like a “Merge Variables” node, and it is not possible for this component to ever see the message “WORLD” internally that came on the lower flow.
We can see that variables came in from both ports, but where the same variable name appears on both, the upper value takes priority. The variables “seen” on both input flow ports of the Component Input node are the same, no matter what the actual input flow variables were.
What I would like to see is a change to the Component Input node, where a configuration option allows us to choose whether it should Merge Multiple Input Variable Flows (i.e. existing/backward compatible behaviour) or Separate Variable Input Flows (i.e. the more intuitive and logical behaviour), compatible with the way that Metanodes work.
A possible alternative solution would be to allow variables from each input flow to be prefixed with a different value for each input,
e.g.
in1:message
in2:message
but personally I’d rather see them stay separate, thereby being an exact behaviour match for the metanode it is supposed to be replacing.
