In some situations (commonly in DW environments) bi-temporality is not enough to capture all the requirements. People usually refer to this as "multi-temporal modeling", but it is actually bi-temporality combined with concurrency. Rather than to introduce more timestamps into the primary keys, we can use another approach.
As I see it, there is a third concept, separate from both normalization and temporalization, and this is 'concurrency'. This can occur over both valid time and transaction time. Concurrently valid values are found in for example multi-language databases or when you need to store both default and actual values. Concurrently recorded values occur quite frequently in for example data warehousing or when many systems are talking to each other.
In order to temporalize an entity over valid time, given its identity, we add a valid period. Any identifier for such entities must contain V_PERIOD (i e in a database the primary key would be composed of IDENTITY, V_PERIOD).
To make this entity bitemporal, a second period is needed, T_PERIOD. Any identifier must now contain both V_PERIOD and T_PERIOD.
In order to allow for concurrent valid values a second identity is needed, that which describes through which perspective the entity is viewed, V_PERSPECTIVE. Any identifier must now contain V_PERSPECTIVE, V_PERIOD, T_PERIOD. Perspectives could be 'English', 'French', 'Default'.
In order to allow for concurrent recordings a third identity is needed, that which describes through which perspective the entity is viewed, T_PERSPECTIVE. Any identifier must now contain V_PERSPECTIVE, V_PERIOD, T_PERSPECTIVE, T_PERIOD. Perspectives could be 'System A', 'System B', 'DWH', 'Filing cabinet 42'.
I am not ruling out that there may be n-temporal things, but the way the discussions have been it's all concurrency in the bi-temporal domain. Since multi-temporal modeling should be reserved for its proper use I propose that we call this type of modeling concurrent-temporal modeling.