Go support is one example. If you set up Emacs to provide decent support for Go at different times between 2015 (when I started using Go) and today, the setup would probably last an average of 18 months or so before you lose something significant and had to sit down and bodge something together to get some replacement for functionality that just died.
I can't remember what specific functionality had just died, but I was in the process of re-doing my Go setup from scratch for the third time or so when I figured I'd give VS Code another spin.
Could that have to do something with changes in go tooling (something that you alluded to in your original comment) rather than emacs itself? I am sorry I am not familiar with the go ecosystem at all.
In my own experience, emacs developers generally have the exact opposite approach and strongly resist any changes that may break existing user workflow. Of course, externally maintained packages might take a different approach because they are developed independently of emacs.
Even if you are not yourself interested in emacs development, you can contribute by just making bug reports for these missing features or breaking changes in the packages that you use. That's just being a conscientious open source citizen.
I can't remember what specific functionality had just died, but I was in the process of re-doing my Go setup from scratch for the third time or so when I figured I'd give VS Code another spin.