Think about cross-cutting concepts like I18N, where an attribute's semantics may be represented by different values based on some property of the environment.
For example, an entity representing the status of a task may be represented by this class
where title is the value displayed to the user and must be meaningful for her. So, if the application is targeted to users who speak different languages, it would be very useful to have the value for title persisted on a secondary table referenced to the primary table by the task id and a language tag.
Currently many developers achieve this using a Map<Locale, String>, but that requires to loose good design (title is a string, not a map), use of validation constraints, it forces to load the whole collection or to use proxies — while if the desired locale is known, the session can join the table using the locale as the discriminator to read/write the single value.
I imagine something like this:
where @Discriminated may have optional parameters to specify table definition.
The I18N example is just a common use case, but I can think about other context-based values such as multi-tenancy, periodic values and so on.