Thanks for your response
I don't see this extension as being useful or necessary for recording the instant at which an event occurred. That's quite adequately handled by simply recording a simple temporal value. The construct doesn't offer any help with modeling repeated times or intervals (e.g. the last Thursday in each month) but those would generally need explicit modeling anyhow. So that leaves the remaining pattern, being for recording non-overlapping intervals, either contiguous (one at a time) or discontiguous (at most one at a time). After single events, this is the most common pattern.
A "one at a time" would record a start time (before which the main player is not allowed to exist to require the constraint to be fulfilled), and any subsequent assertion closes off that interval and must begin a new one, triggered by a simple update request. Deleting (actually retracting the validity of; soft deletion should be automatically correlated) the main player also closes off the outstanding interval. So if a Person was born into the Smith family, their surname would be asserted as Smith from the moment of their birth registration (or whatever), continuously until their name was changed by marriage or deed poll. At that point, the open validity period associated with their name being Smith would be closed off, and a new one opened with their new name. On the other hand, by implication, the use of "at most one at a time" implies that it is possible to close off an existing open interval without opening a new interval.
Some of the temporal patterns relate to different ways to map "one at a time" and "at most one at a time" patterns, rather than conceptual differences, so in most cases I'd leave the choice between patterns as a mapping option or default. Even granularity is often sub-conceptual, which is why I relegated it to a lower level. You could introduce that directly by saying "one in each day", "one in each second" as opposed to the default, which means one in each instant.
As for valid time vs transaction time, ActiveFacts already has a variable "Now" (defaulting to the system time) which can be set to the time at which the current transaction is to be considered to be processed. If it's set in the past and a change is made, there would need to be validation that the change didn't unexpectedly contradict existing accepted facts.
Because of the requirement of soft deletion if a temporal mandatory uniqueness is applied, it may be necessary to incorporate "at a time" semantics into the identifying uniqueness constraint of the main player, for example the Person in the example above. This allows a Person to be identified by past roles that currently identify a different Person, such that other facts in which the earlier Person was involved ceased being valid when or before their identification expired. The alternative to soft deletion is to disallow both deletion and closing off the mandatory fact.
A feature not obviously covered by this proposal is where the states of several facts relating to one player are anticipated to all change together, and so a mapping option is needed to group them for efficiency (even if not all must change on each such transaction). Again though, that's sub-conceptual, it's just a mapping feature.
I think this feature would provide a very effective way to hide complexity in many models, especially ones where an audit trail must be kept. Such models can be incredibly painful to build, understand and use, and a simple extension like this would be a huge boon. If necessary, a tool can allow the hidden temporal roles to be "folded" and "unfolded" so that additional constraints can be applied to those roles.