Unix-stuff as a part of the standard library is a terrible idea. Making your own crate is simple enough. Same with OS-dependent functionality.
Re: crates namespaces, that is a crates decision, not necessarily Rust'. You can always publish your crate on github and include it with "package = { git = ... }" and you'll get the same thing as in go.
Why is that not true for the rest of the standard library? You don't really need a HashMap in your standard library, or mutexes, just a memory allocator and atomics.
Historically, the criteria for inclusion in the standard library is, does it fall under one of these three categories:
* Used in the vast majority of Rust programs.
* Reasonably common things that require a lot of unsafe to implement.
* Traits for interoperation purposes.
HashMap and mutexes fall under #2. The idea is that they'll receive significantly more scrutiny, and this is a good thing for the ecosystem.
(These are guidelines, not hard and fast rules, so not literally everything fits here, but that's the framework that was used to think about what should be included or not, generally.)
To be honest I think #2 was applied a bit too broadly. Sure rustc gets scrutiny but the std isn't the easiest library to contribute to. Not only is it large (by rust crate standards) but it's also tied to the compiler which adds another barrier to contributions.
Mind you, increasingly parts of the std are more like wrappers around third party crates e.g. hashbrown and parking_lot.
If the "platform" concept works out then those things probably should move out of the standard library. Look at how many people had to upgrade language versions to deal with DoS attacks on their HashMap implementations, when it should've been just a case of upgrading their HashMap library.
Re: crates namespaces, that is a crates decision, not necessarily Rust'. You can always publish your crate on github and include it with "package = { git = ... }" and you'll get the same thing as in go.