Interesting overview!
While having a garbage collector is kind of standard, the Go one is a bit special.
Most languages with GC, like Java, are focused on reference types. But Go could I think be fairly described as value-oriented, like C.
That is, rather than most variables being pointers to separate objects, they are stored directly inside eachother and on the stack by default.
This apparently had some interesting effects on the design of the garbage collector.
Another special thing, and arguably one of the most famous, are the goroutines.
Many languages now use async/await for IO and real threads for parallel computations. There are no multiple stacks, and context switches are explicit (or kinda in Kotlin).
Erlang has a somewhat similar system, also with growable stacks. But they behave more like processes (no data sharing), and they are pre-emptive (they can switch at any time).
Java and Rust abandoned green threads, which would be kind of similar. I'm not sure which other languages have something like it built-in.
So I think Goroutines are kind of special. They only switch at specific points (when blocking waiting for IO or channels, usually) which is like async/await. This is often more efficient than pre-emptive.
But unlike async/await, there are no async or await keywords. If your function can yield execution, the callers won't know about that. Which related to their implementation as actual stacks, instead of just compiler magic. On the one hand, it means less syntax is needed (marking all functions as async), but it also means you don't really know when you're going to be interrupted and your state changes, just like real threads.
That said, to my taste Go is too spartan. I get how it follows from their goals, but I think the simplicity is mostly nice in the first half year. After that you'd be happy to have generics and other features that help you write more reusable and reliable code.