Many of the points you mention are fairly low hanging fruit for inclusion if you are willing to accept the tradeoffs that official Go maintainers are not willing to.
What we have here is people who are already heavily invested in Go to the point where its type system is a real problem for them, yet they do not want to fix the problems, even in light of the relative ease at which at least some the problems can be solved (again, if you are willing to accept the tradeoffs).
You could fork Go and add generics support, but you'd be maintaining that fork forever. The Go core team would never allow it to go back upstream.
The group of people who are able to fork, change and maintain their own Go variant are usually not the people who would ever consider using Go in the first place.
Have a look how long it took PHP to get an AST (instead of the broken mess of reading&executing). Those who are able aren't those who would ever deal with PHP.
I think some of the best parts of Go is the central model: "go get", "go fmt" along with the standard library - if you fork, the burden falls on the fork keep all that stuff working in a sensible way too.
- OCaml is great but parallelism is still limited by its "Global Interpreter Lock" (like Python or Ruby).
- Rust is great but ownership/borrowing is not for everyone and people sometimes prefer relying on a good garbage collector.
- Nim is great but it's a "small" project compared to Go and most people prefer relying on a large ecosystem like the one offered by Go.
- Ada was a major milestone in the history of programming languages, but it's considered by most as an "old" language, compared to Go/Rust/OCaml/Haskell/Scala/etc.