I believe this is reference to Go's approach, where code can be written in a linear straightforward fashion with normal function calls, but, if they are syscalls then they become async automatically.
I don't think it's appropriate for the level of coding that Rust is targeting... But... It would be nice.
I suppose that makes sense given OP's definition of "no dependence on run times", but I think I'd have to agree that that approach probably wouldn't work well for the niche Rust is trying to target.
That's technically POSIX, not standard C, isn't it?
But in any case, I'm pretty sure Rust has supported the nonblocking functionality you want for quite a while now (maybe since 1.1.0)? You'll need to piece it together yourself and use the libc crate since it's a platform-specific thing, but it doesn't seem too horrendous. Ultimately it comes down to the fact that the fundamental method for the std:io::Read is
which is perfectly compatible with non-blocking reads. For example, std::io::File implements Read and std::os::fd::FromRawFd, so if you can get a non-blocking file descriptor you should have non-blocking reads for files.
What approach are you thinking of for the API of those functions, since async/await is not something you'd like to see?