Bitemporality is an under-rated and rarely discussed database concept. It is similar to the idea of "reproducible builds" but in a data model context. It can be indispensable for some applications.
Efficient implementations of bitemporality require first-class design support in the underlying storage engine, you really don't want to paste it on top of an existing storage engine not purpose-built for bitemporality if performance matters. Write throughput in particular tends to be terrible without a fair bit of clever engineering.
A number of database engines effectively implement limited support for bitemporality exposed as narrow features that take advantage of it, but don't expose it as a general purpose facility because of the engineering implications of supporting it in the general case.
I think the biggest reason why bitemporality hasn't seen widespread adoption is that it's a hard problem, both for DBMS implementers to solve and for users to adopt, when constrained to a world of SQL and tables.
Crux not only has first-class support for bitemporality in the core engine but saves the user from having to worry about how and when bitemporality impacts the schema. This is because everything in the database gets a bitemporal history by default, without the user needing to make upfront designs & decisions.
Point-in-time Datalog queries traverse the entity graph using a very simple schema-on-read behaviour and this can serve as a foundation for more complex relational modelling and constraint enforcement.
Efficient implementations of bitemporality require first-class design support in the underlying storage engine, you really don't want to paste it on top of an existing storage engine not purpose-built for bitemporality if performance matters. Write throughput in particular tends to be terrible without a fair bit of clever engineering.
A number of database engines effectively implement limited support for bitemporality exposed as narrow features that take advantage of it, but don't expose it as a general purpose facility because of the engineering implications of supporting it in the general case.