Same applies with manually memory management, you get instead slower allocators unless you replace the standard library with something else, and the joy of tracking down double frees and memory leaks.
I'm using Rust, so no double frees and no accidental forgetting to call free(). Of course you can still have memory leaks, but that's true in GC languages too.
That is not manually memory management though, and it also comes with its own set of issues, like everyone that was tried to write GUIs or games in Rust is painfully aware of.
That's true. The comment by mlwiese up-thread, that I responded to, praised Go's low GC latency without mentioning the heavy memory and throughput overheads that come with it. I felt it worth pointing out the lack of a free lunch there; I think a lot of casual Go observers and users aren't aware of it.
Agreed, although if Go had proper support for explicit value types (instead of relying in escape analysis) and generics, like e.g. D, Nim, that could be improved.
I don't think that's as hard as you make it out to be. Notably, Zig does not have a default allocator and its standard library is written accordingly, making it trivial to ensure the use of the appropriate allocation strategy for any given task, including using a debug allocator that tracks double-free and memory leaks.
No, and as far as I am aware it makes no attempt to do so other than some allocators overwriting freed memory with a known signature in debug modes so the problem is more obvious.