I know how hard it is to document ambiguous concepts.
You start by carefully write the rules, maybe with some illustrative examples, and think you have done your job.
Then you realize that users are unable to perform correct derivation from the rules. They fall into wrong conclusions, forget about edge cases, misunderstand key concepts, and generally happily shoot themselves in the foot.
Time makes it even more difficult, since the behavior of time isn't constant. Most code usually work, until it does not.
When you think that you've avoided all DST-related problems by pushing them to calendrical computations, boom the leap seconds bite you in the face.
One way I know to avoids this trap is to not only document the rules, but also guide users in "real-life" use cases.
For example, can I schedule some code to execute at the end of an animation that lasts 1 second? I never heard of animations of "1 second" that can last between 0 and 2 seconds of absolute time because a leap second happens to be inserted or withdrawn at the most unexpected moment. So can I execute some code in one second of "animation clock", and get perfect synchronization with my user interface? Which one of the clock described in this proposal should I use? Does it even exist?
There are many more use cases that the fertile imagination of the community can invent. How does this proposal addresses them?
Answering such questions would help the proposal authors feeling confident that their proposed api addresses users' needs. And it would also help the community share a common understanding, and feel confident that their needs are addressed. I know this is a lot of work. This work should be done by the proposal authors.