One of the areas I feel somewhat 'underserved' by research as well as open source & commercial offerings -- is the notion of time, in the data evolution model. Datomic had taken a stab at it, and somewhat emulated what is known as 'persistent data structures ' -- that is data structures that preserve state of the data a given time.
In my professional career, I had designed out several (enterprise-internal) implementations of this concept using basically hand-designed notions of time evolution, state management, etc.
I could not find (perhaps I have not looked hard enough) for easy to explain / build relational algebra, across separately evolving (evolving in time) data and what relational operations are valid vs invalid in those models.
These kinds of problems arise very frequently and many of the domains.
For example, say take financial services.
There are Counter parties (parties in the contract), there is the Derivative contract (that describes the underlying behavior + the base instruments), then there market events, and then there are credit-events and credit worthiness associated with the parties.
All these legs (parts), evolve independently in time. So my typical data models included a bi-temporal setup (where both system time, and business time are included) for each.
This way, I could build Domain specific query language(s), around these time-aware evolution legs. And those languages would constrain the users/client applications -- what they can ask, what parameters (especially time parameters), they have to pass in, etc.
However, I found it difficult to evaluate and pre-build constraints that would prevent submitting 'invalid' queries -- where the say a client would be asking my system: for data (state), that based on a relational query -- but some parts of the relation, did not exist at the time (or there were multiple changes to one of the relation within an assumed interval -- and therefore it was ambiguous, what exactly they are asking about).
In other words, what I could not figure out, at least at that time -- a constraints model around the relations, in separately-evolving 'sub sets' or 'sub-states' of the overall data.
This is probably similar to trying to relate entries from separately evolving block chains/distributed ledgers.
There are tools (even built into databases) that make time arithmetic easier (eg Allen Algebra is built into several database systems) -- but that's really just a form of 'interval algebra' and not really a foundational (or technical implementation) of the time-centric relation algebra.