I understand your general preference @daurnimator to move stuff out of std/os.zig. I'd like to handle that proposal separately. I think there is something to it, but I also think that the premise of this PR as it stands is sound. The comment at the top says:

// This file contains thin wrappers around OS-specific APIs, with these
// specific goals in mind:
// * Convert "errno"-style error codes into Zig errors.
// * When null-terminated byte buffers are required, provide APIs which accept
//   slices as well as APIs which accept null-terminated byte buffers. Same goes
//   for UTF-16LE encoding.
// * Where operating systems share APIs, e.g. POSIX, these thin wrappers provide
//   cross platform abstracting.
// * When there exists a corresponding libc function and linking libc, the libc
//   implementation is used. Exceptions are made for known buggy areas of libc.
//   On Linux libc can be side-stepped by using `std.os.linux` directly.
// * For Windows, this file represents the API that libc would provide for
//   Windows. For thin wrappers around Windows-specific APIs, see `std.os.windows`.
// Note: The Zig standard library does not support POSIX thread cancellation, and
// in general EINTR is handled by trying again.

In particular 3 of these points apply to nanosleep:

• nanosleep is a libc function, available on linux, freebsd, macos, netbsd, and probably more. os.nanosleep provides cross platform abstraction over these.
• on linux when not linking libc, os.nanosleep provides abstraction over calling the libc version or the linux syscall directly.
• the possible error of nanosleep is converted to void meaning that it cannot fail (by adding "spurious wakeups are possible" to the documented behavior)

On the other hand, the decision to make it work for Windows is questionable. nanosleep is not a Windows API function, either directly or in msvcrt. os.nanosleep could have Windows support removed and that logic can go directly in std.time.sleep, and become simpler. That's probably a good idea.

Originally posted by @andrewrk in #2527