Should std have abstract OS IO?

> So, no, it is not a requirement that std has to wrap any wrappable IOing API. This could be handled by the library ecosystem, if the language allows first-class bindings to raw OS APIs outside of compiler-privileged code

I... yes? But just because your language allows you to drop into assembly, or allows you to link against foreign functions, or however else it does FFI, that doesn't mean that your stdlib should contain only algorithms and data structures sans IO.

Let's take it to the absurdity and imagine a language which doesn't have even the standard halting continuation — i.e. that part of the runtime that calls sys_exit()/ExitProcess() — in its standard library (or its runtime). Is this reasonable? No, I don't think so: just because sometimes it is nice to have ability to not have this part of stdlib/runtime linked to your program (and Rust/C allow for that), that doesn't mean you should leave it to the community to figure out.