Create a language for each tenant, this is what I did to create a multi tenant application with one tenant requiring a formal tone and one requiring an informal tone, while both tenants used the Dutch language.
Rom van Arendonk
We use a hybrid sollution. We do create a seperate table. In the table we have the enumeration and we have a calculated field with the translation (see forum post about translatable data). This way each client can have it's own set and it is translatable to other languages and we can still use the enum for conditional visibiltiy etc.
I encountered this with multiple clients before. We created a separate List of Values (LoV) module for this with 4 entities:
LoVType: the type of the enum
LoVValue: the values for that enum;
LoVTranslation: the translation for each LoVValue. a calculated attribute based on the user language;
LoVCondition: can be used to create parent child relations for cascading LoV. Associated LoVValues to other LoVValues.
The normal business attributes would then be associated to an LoVValue, which is restricted by the above setup.
As discussed outside of this forum there is a way of making your second scenario work, and since other people may face similar problems I'll post it here as well:
for your 'Do not use an enum, use a reference selector to a new entity. This makes my users unhappy because they like selecting via a radiobutton here and not a dropdown list' option there is a way to keep them happy, that way being the (platform supported) widget Radiobutton List. It lets you easily display and select references using radio buttons.