C#'s problem is it's quickly becoming C++ in that it doesn't just have the kitchen sink, it has three kitchen sinks...
Unlike C++ though, one day the powers that be will just remove features as part of yet-another framework rewrite and you'll just have to deal with it.
The other issue is just how tightly coupled C# as a language is to the .NET framework/platform. Some of the things people like C# for are actually framework things and they don't realize it because that separation isn't as clear as with Java and say, JavaEE or Spring or $X.
If you talk to a C# developer - of course they're using .NET and of course they're using Entity Framework - to them, there's no other way. It's inconceivable that any other library or framework might do it better than Microsoft's official offering... and then you'll find the official offering to be lacking in fundamental ways.
Talk with a Java developer and you'll find there's a lot more diversity of frameworks and libraries being used - so there's a lot more differing opinions on priorities and a lot more good ideas being tried out or implemented everywhere. The communities are vastly different in that regard.
Collection literals are a pointless extension of the pattern matching syntax added to get around the fact that there is no way to name a generic type in C# without specifying its type arguments.
It's yet another double down on object initializers instead of writing constructors and factories, and unlike using a factory you have to fully express the result type of the collection instead of having it inferred (they are "target typed", another feature that probably should not have been added).
There is a pattern matching aspect but I think the energy behind it is largely motivated by a desire to clean up syntax when working with data structure based APIs and DSLs.
I've read the proposal, design meeting notes, and GH conversations. Not seeing a compelling counter argument here.
