Additionally, if the original geometry is not connected to the top of the multi input of the join node, then all material indexes are set to 0. I'm guessing this is a safety measure to make sure that if materials aren't present in the materials shader panel, then everything will revert to 0. This is a terrible idea considering the materials can be added to the node tree at any point. This should always be left at whatever the user sets it to rather than assigning it a 0 if there's no material with that index currently.

Below image shows that plugging the original mesh into the bottom of the join node results in the top two mesh's being given a material ID of zero instead of what was specified. This is bad, but additonally, even though there is a material with ID of 0....no material is rendered (middle 4 cubes).

Hey @Jacques Lucke (JacquesLucke). I can understand the need to change material indices and associated attributes where conflicts arise from merged objects, but they should always be given unused slots and leave any tree specified material indexes alone (it would be nice to show this relationship in the spreadsheet, perhaps have the material name in brackets beside the material index). In the case above there are no material conflicts, so can you explain further why it needs to set both material indices to 0 if there are no conflicts?

@Jacques Lucke (JacquesLucke) for example here. I'm not sure if you've looked at the file properly. But below you can see there are no conflicts, yet the join node has created a third empty material and changed the attribute we specified as 0 to 2..so instead of getting the existing checkered material which has mat index 0, it gets a non existent material...

@Jacques Lucke (JacquesLucke) and here, again, no conflicts, but again it's changed all specified material indices to 0. This is because if the materials don't exist on the branch connected to the top of the multi input socket, then it incorrectly thinks there are no materials available on the other branches or at the object level, and breaks everything. Maybe it could check all branches before deciding on availability? And if all branches have no materials, then perhaps it should check the object level materials (from the properties panel)?

The join geometry node is currently allowed to change the material indices however it wants as long as the materials are kept intact (not necessarily the material indices). I could go into the code to figure out why it is doing exactly what it is doing, but that would not fix anything. It's perfectly valid for the Join Geometry node to reorder the materials even if that is not absolutely necessary.
As said, we could have a boolean input to disable this special material handling, but I don't think that would be a better workflow in practice.