It is possible by completely legal content & data manipulation via admin UI to take the product categories to a unique constraint violation leading to some crashes and inconsistent DB state.

How to replicate:

[1] Create new category "Y" in eng-GB: name="Y EN", identifier="y_en".
The Y's identifier in ibexa_taxonomy_entries (in DB) is now "y_en".

[2] Create new category Y's translation in pol-PL: name="Y PL", identifier="y_pl".
The Y's identifier in ibexa_taxonomy_entries is still "y_en".

[3] Create new category "X" in pol-PL: name="Y PL", identifier="y_pl".
The X's identifier in ibexa_taxonomy_entries in DB is now "y_pl".

The taxonomy table looks now something like:

identifier | name | names
y_en       | Y EN | a:2:{s:6:"eng-GB";s:4:"Y EN";s:6:"pol-PL";s:4:"Y PL";}
y_pl       | Y PL | a:1:{s:6:"pol-PL";s:4:"Y PL";} 

[4] Update Y's main language from eng-GB to pol-PL. There's no change to both ibexa_taxonomy_entries identifiers, all seems OK.

[5] Now remove Y's eng-GB translation (only the secondary translation, not entire category!).

 [6] At this point, there will be a red notice about constraint violation. Working on those categories now will lead to system crash because DB taxonomy entries were left in an inconsistent state.

Additional info:

It may be easier to encounter this problem because of the issue IBX-8577.

However, it doesn't seem to be the core issue here. It seems that in case of tags, the taxonomies engine is capable of holding to a once-selected unique identifier even when it's translations get removed. I wasn't able to replicate the same problem for tags. In case of product categories, the logic of calculating/retaining the unique identifier seems a bit different to the one in the tags.