An entry can belong to one catalog. All other catalogs are linked. For that reason we don't think we should allow multiple primary NodeEntryRelations. But as always we are open to suggestions. Why would you want to do that?

Maybe it's just a lack of understanding on my side regarding these details but considering that an entry can only belong to one catalog, say the Swedish catalog in our case. If we have this fictive category structure:

Swedish catalog 

--- Category A

--- Category B

Norwegian catalog

--- Category C

--- Category D

In the Swedish catalog we want to make it clear that the primary category for the entry is "Category A" and in Norway "Category D", this is not possible with this limitation. If we do set "Category A" as primary NodeEntryRelation and "Category D" as a non-primary NodeEntryRelation, looking at the entry under the Norwegian category tree in Commerce will show the user that the entry's primary category actually is a category in the Swedish catalog, which might be a bit confusing I guess?

Interesting. I still think an entry should belong to a catalog, and that kinda contradicts with two primary nodes. If the editors understand that rule then it will be not confusing to them, I suppose

Then we'll do as we're told () and stick with one primary category, most probably the one that is located in the same catalog as the entry belongs to. Thanks for your quick response Quan! 

The concept of a primary category is also defined by its mapping to the ParentLink of the content model. ParentLink can only represent one parent relation. ParentLink is in turn used for example when building the default route, where again multiple values are not possible.