We are actually moving towards a two timestamp implementation for bitemporal modeling in our new concurrent-temporal technique. One for valid time and one for transaction time, which we refer to as changing time and positing time respectively.
The advantage is that you will never have to execute UPDATE statements against your data when you use single timestamps. Another advantage is that you get a gapless timeline over valid time, which you otherwise would have to ensure using additional logic. Furthermore, you never have to reorganize your data, even if you have late arriving facts. They can just be inserted between any two sequential rows, and the timeline will be rearranged by itself. Finally, it also avoids bad modeling practices that otherwise would be an option, such as null values or having to introduce an until-the-end-of-time concept.
The cost is that you get a slightly more complex query at SELECT time. However, since that logic is taken care of in our automatically generated perspectives, it does not become a use-case problem, but may affect performance.
You do not lose any capabilities, since as you asked, the closing of an interval is implicitly determined by a "later" row for the same identifier. You also save the storage space two additional columns would induce. All in all, single timestamps give less maintenance and less headaches, which is why we have chosen this path, as opposed to how it was done in early research of bitemporality.
