Overall, yes, but mostly I'm surprised to see this as a Foundation proposal rather than as a stdlib proposal. Of course, doing it in Foundation doesn't necessarily preclude later adding it to the stdlib, but it might make it harder to do so.
Every other language I can think of includes this functionality in the stdlib:
C gmtime, C++ utc_clock, Rust SystemTime, Ruby Time::utc, Python gmtime, Haskell getCurrentTime, etc.
Is the argument that the stdlib doesn't want to include more large chunks of ICU, sufficient justification to put this in Foundation? Or should we take a more pragmatic approach like Rust, and reduce the functionality to the point that we only need to call clock_gettime?
The topic of whether Date should move to the stdlib, and whether Date should change its representation from Double to something accurate, comes up pretty regularly on these forums. It seems like this proposal is an opportunity to reconsider both things, or to consider a third option such as adding an accurate UTCTime to the stdlib, and conversion methods to & from Date in Foundation.
I agree with the other reviewers that the name of the epoch property shouldn't be misleading. Notably in prior art, Rust provides UNIX_EPOCH on all platforms, but doesn't offer the system epoch. I think the argument on that page about needing this constant for a lot of internet protocols is good justification to provide the unix epoch unconditionally (whether or not you also want to provide the less-standard Foundation or Windows epochs).