That is a fair critique per the protocol. I'd like to get commentary from the Darwin kernel folks on the WallClock versus SystemClock (since after all they are a big player here that I am attempting to represent).
This somewhat flows in the terminology I started off with of ReferencePoint (which was perhaps too general). One part that the Instant terminology offers that I am not sure PointInTime etc does is the non-timezone, non-calendrical, non-local aware time value nature. Particularly the sticky one here is the wall clock case; I would accept the concept that the naming would be Clock.Time is required to be an Instant if we really wanted to go the route of "dropping the protocol suffix".
Yea this is not an easy concept to square between platforms. Darwin has the concepts of "absolute" time, "continuous" time and realtime/wallclock-time. In that parlance the absolute time is most close to CLOCK_MONOTONIC from linux, and absolute time on Darwin is CLOCK_UPTIME_RAW (with a timebase adjustment). To follow continuous time is most close to CLOCK_BOOTTIME on Linux and CLOCK_MONOTONIC on Darwin.
I didn't feel like it was apt/fair to name these clocks in that parlance of absolute versus continuous clocks and force that nomenclature upon all operating systems that Swift runs on. Admittedly it is perhaps my personal bias to liking Linux as a OS that favored the naming to use the Monotonic/Uptime prefixes and my bias as being an engineer working in Apple ecosystems that influenced their behavioral defaults.
The problems you outline w.r.t. ticks while sleeping are specifically why having both a clock that progresses while asleep and a clock that does not is useful out the gate. However I would dispute the conclusion that Go came to, because transmitting boot time across a network could lead to security vulnerabilities and in the end if you think about it the boot time of two machines is never identical so their boot time based clocks are going to be skewed. WallClock instants are really the only suitable distributed system clock basis since they are synchronized to NTP. (but perhaps their assertions were more so talking about networks on the local machine?)
Absolutely; the proposal includes both an UptimeClock and a MonotonicClock (just with the Darwin and BSD definitions of their behavior).