There are a ton of Go features that have been asked for by the community that have taken years to get mainlined. I think the most common examples are generics and package management. The authors of the language tended, at points, to be at odds with the desires of many in the community.

Even in those areas, however, Go hasn't done the things that Elm did (according to this article).

There have been a lot of experiments with Go package management, and some did get fairly widespread adoption. After many years, they are getting replaced with an official way, and there are some hard feelings, but experimentation and adoption of alternate solutions was never forbidden. Even with the official system, you aren't locked into the official package management infrastructure; there are flags and environmental variables you can set to use your own servers.

There have also been a lot of experiments with Go generics, often implemented via a preprocessor. I don't think any of these got a lot of traction, but again, they weren't forbidden.

Ultimately, the Go team decides based on what they think is right, but at the same time they aren't so insecure about competition that they need to suppress it.

Maybe, but the Go authors never banned people expressing disagreement or people forking the compiler or the tools.

Almost all programming languages have features being asked by the community and not available as soon as one would hope. Modules in C++. Value types in Java. Removing the GIL in Python. Parallelism in OCaml. Higher kinded types in Rust. Etc.

And most of the time there are pros and cons to adding these features or not, which sometimes evolve in a debate fracturing the community. It even happened to the otherwise peaceful Python community with Guido quitting after the decision of assignment expression: “Now that PEP 572 is done, I don’t ever want to have to fight so hard for a PEP and find that so many people despise my decisions.”