[kevingadd]

The emphasis on syntax sugar has a very useful side effect, which is that new language features can be used on old runtimes. To this day some of the newer C# features are usable when targeting the ancient .NET Framework 4.x, like 'ref returns'. This would not be possible if every new language feature was paired with runtime-level changes. (Many new language features do come with changes to the runtime and BCL). I support a bunch of people who use NET4x to this day and I'm able to write modern C# for that target thanks to the language and compiler being designed this way.

A lot of stuff is also designed to be independent of library changes - IIRC for example if you use nullability, the compiler will emit the Nullable attribute's definition into your .dll as a hidden class, so that your library will work even on older versions of the runtime with older base class libraries. Doing this complicates the compiler (and adds a tiny, tiny amount of bloat to your dll) but means that more people can adopt a new feature without having to think about upgrading their SDK or runtime.

My personal opinion is that if a change can be done adequately entirely at the compiler level without runtime/library changes, it should be done there. It allows the people working on the language, libraries and runtime to iterate independently and fix problems without having to coordinate across 3 teams.