Say you do a full outer join on the "compound ID" column that exists in both tables (but it could also be called "compound ID" in one, and "compound code" in the other), the compound ID column from the left-hand table remains empty if that particular compound only exists in the right-hand table. Then before being able to do another join (or doing anything else), first the "column merger" node needs to be applied so that every row has the identifier in the same column. It seems to me that if you're doing an outer join, you automatically want the compound ID column to be merged into the left-hand side compound ID column (or at least have this an option). Since you're joining on them, presumably the columns are considered to be the same.
I think that is a good idea, thanks for the suggestion!
I second the request - though I consider this a bug rather than a feature.
If the Joiner node is mimicking database operations then this does not currently conform to expectations. The joining columns should be merged by default. Having an output containing missing values in the join column is undocumented, confusing and incorrect.
I had a closer look at this, and I actually think the current behavior is correct. One weakness with automatically merging these columns is that you loose information about where a partiuclar row comes from, which can be useful information and is computationally expensive to recompute, say with a reference row filter.
Also, wikipedia says so :)
I see the point and also believe that one would want to merge the two columns in most cases.
Nevertheless: Another argument for keeping this feature in a separate node is the fact that the Joiner already has a quite complex user interface. (And this feature probably would have to be optional simply to keep the node behaviour downward compatible.) For less experienced users, it is already difficult to predict the output of this node and adding yet another option (that is only relevant for the less frequently used outer joins) would certainly not help and force such users to do even more trial-and-error configuration.