> Why would you stop at two time axes? Why not go for three, or four, or N many?
This question is confused, because it's taking a derived property as fundamental. It takes as fundamental the fact that there are two associated times, rather than as fundamental the fact that there are these particular associated times, of which there happen to be two. If you can't think of a particular third associated time to add, the idea of "going to three" is meaningless on its own.
My mind immediately jumps to thinking about branching valid time timelines, but having thought about this a _lot_ over the last few months I think actually all other kinds of timelines can be implemented using valid time + additional indexing.
I thought about it, too, but I guess then you really dive into the field of versioning systems and probably it won't be a database system anymore. That is also manual conflict handling...
I think branching/merging itself wouldn't be that hard to implement, at least if you have a versioned index at the very core (disclaimer: I'm also developing an Open Source temporal storage system). But then you'd have checkouts, handling conflicts...
Additional time axes allow you to separate transactions from different sources of input. E.g. in a collaborative system it could be helpful to ask questions while rewinding the actions of a particular user.
But a different question is whether the system can do something useful for you with first-class time co-ordinates, compared to just stuffing additional timestamps into your data. (something useful being clever indexing, compaction, maybe more?)
This question is confused, because it's taking a derived property as fundamental. It takes as fundamental the fact that there are two associated times, rather than as fundamental the fact that there are these particular associated times, of which there happen to be two. If you can't think of a particular third associated time to add, the idea of "going to three" is meaningless on its own.