So this is similar to the talk from Russ - they don't want a wish-list of features or problems chosen to illustrate a feature you have decided you want, but a list of concrete problems with ecosystem, libraries, language which people who actually use Go have found when using it.

So give them well described problems, not solutions.

As an example you could say I want generics, but it's pretty pointless and an example of providing a solution not a problem. Better to say - containers in go suck because x,y,z, we want to use a red black tree for 10 diff types and it's painful, we generate go code and it's painful, I want to use range on my own types etc, or unboxing typed arrays is painful, or I want better error handling, option types etc, because that lets them see what flavour of generics (from the many possible choices) are actually required, and which bits of the language/tooling etc need improved, specific to go.

My bet is they will go with some form of generics in Go 2, the question that is completely open is what form it will take, which will be affected by exactly what problems they have described to them. Nobody is obliged to waste their time doing that, but if you want to influence the Go team, I'd suggest doing exactly what cloudflare did after the monotonic clock issue - describe the problem and why the current solutions don't work. They actually mention that in the talk and Q&A here and say their initial instinct on the clock was wrong, and seeing the concrete problem helped.

Lack of generics has not stopped my using go professionally (or you), and in my experience has been a minor wart rather than a blocker (this may vary for you). For me it's not a huge problem, I'd rather see errors cleaned up.

There's also a long q&a at the end which in a way is more interesting than the talk and ranges over a lot of topics from json speed to external package repos, packaging, use of go for mobile.