Would it be a useless option to generate master data tables for the user application based on the domain elements and their translations, as part of code generation? Not just as a comment in the checks-codegroup, but as real tables and data?
I am aware that it is of no use for the end user that already sees the translation in the application, but any application manager or support team would be helped by it.
Developers for sure would be helped, because they do not need to query the SF to find the meaning of the domain elements and instead can join the master data to find the meaning of a value.
Domain elements have the benefit of enforcing data consistency, but the drawback of needing developer intervention to extend the number of elements. Therefore I often see customers asking to revert a domain with elements to a master table with a prefilter.
Imagine a scenario where domains come with built in support for inactive domain elements. The database value of the element does not have a meaning (other than for ease of mind for the developer), so when requirements describe ten elements, we would create twenty, ten of which inactive and reserved for future use.
Now when the application manager wants to add a new domain value, it will be taken from the reserved values without need for changes to the database.
(*) user maintained domain elements still require developer intervention to update the name and translations of those 'new' elements in the SF/model. That is a solvable problem.