This part is definitely a needed item. The reasoning for a wall clock based instant is to provide a type suitable for deadlines in distributed actor scenarios. The moment a transport communicates a deadline across the wire to a distributed actor that means that the two machines involved need to have a shared agreement on time.
Obviously using an uptime clock in that case is distinctly flawed for a number of reasons, namely of which the two machines will never have been booted precisely at the same time, but also it exposes a potential security vulnerability. Monotonic time also has a non shared frame of reference similar to uptime (this varies a bit more per platform but practically is often a boot as zero reference point style instant).
The next logical question is; why do we need to use instants as the transport for deadlines? Why not timeouts (read Duration)? In that case the deadline based on a timeout is not composable, any attempt to compose that would gain strange drift on the deadline where the access to now ends up taking time out of that deadline. Using a distinct instant means that the actual deadline for work is preserved without needing to recalculate per frame.
So in order to offer the transport layer for distributed actors; we need a concrete type suitable for expressing a shared and agreed upon frame of reference for measuring time. The available concepts across swift's target operating systems that are supported (and pretty much all of them that I can even think of) have a concept that does precisely this. The root derivation of clock_gettime(CLOCK_REALTIME, ...) or its equivalent exist on all platforms (granted the API names may vary a bit here and there). That all boils down to the fact that we need something below (or at the same layering level) distributed actors to offer them the right type. This means that the Concurrency library/standard library is the right place for that thing.
I am quite certain the concerns have been heard, and well understood by now that there is a conflation between dates for computers and calendrical dates. I have some time set aside today to talk with some of the responsible parties and I will make sure to report back here once I have more details. Suffice it to say there are a lot of considerations to make here and we need to make sure to offer APIs that make sense but also need to balance supporting existing usage.
To be clear, this is just the start of a few proposals and work in this area; I know it can be frustrating to feel there is an opaque layer involved, but moving types down is a good way to start to remove some of those barriers. Everyone benefits (in my personal opinion) with things being more open.