Data races are a source of bugs. They are not a noticeable fraction of the security issues that face memory unsafe languages, which is the practical argument for memory safety.
I was discussing data races in the scope of all memory unsafe languages, I don't really know enough about Go to know whether people are looking for these.
They are, pity that Rust type system has nothing to prevent them outside a very specific use case of in-memory data structures and threads.
Make those in-memory data structures writable via OS IPC and all bets are open, regarding what other processes, or kernel extensions, do to the memory segment.
Fearless concurrency is welcomed, but lets not overlook the fine print in systems programming.
If you have both sides cooperating, then it's perfectly reasonable to write a safe interface on top of shared memory. If not…well, what do you suggest? Also, pointing at the overwhelming majority of code and going "this is a very specific use case" is also kind of wild, because even in IPC scenarios there will be in-memory data that needs protection.
Nope, because it depends on how memory storage is mapped on the process, linker scripts and other fun tricks in systems programming, outside Rust's type system.