22 новых фичи C# — каким будет C# 11+

Частота применения, конечно, субъективна и зависит от сценариев. В WPF это действительно большая фича, но в вебе такое нужно крайне редко, а в Unity не берусь судить. При этом в WPF иногда делают нотификацию изменения объекта через аспекты и тогда field не нужен. Ещё field не очень хорошо сочетается с первичным конструктором, который будет создавать поля явно.

required действительно выглядит как потенциальная смена парадигмы инициализации объектов, к которой нужно будет допиливать экосистему ещё. Потому что, например, record выглядит прекрасной фичей, но с AutoMapper сочетается довольно плохо. Если PostInit  конструкторы хорошо встроятся в DI, первичные конструкторы и другие фичи с полями и свойствами, то это будет интересное изменение. Это будет довольно сложно успеть к C# 12, так что пока значимость фичи не так понятна.

Это правда, хотя часть из описаных фич уже доставлена в C# 11 preview и много находятся в разработке или ревью уже сейчас. С большой вероятностью большая часть из описаного успеется к выходу C# 11 или по крайней мере не будут выброшены совсем.

Но при этом для некоторых фич всё ещё идут обсуждения дизайна и конечный вариант реализации может поменяться. Например, мне кажется, что params IEnumerable<T> всё-таки не завезут из-за избыточности, а модификатор уровня доступа для области видимости в пределах файла вообще болтает — то ли он будет private, то ли всё-таки file, а ещё там в комментах сразу думают над модификатором уровня доступа в пределах неймспейса.

В той же папке с пропозалами есть не только те, что сейчас в работе, но и отложенные/ожидающие — у них вероятность доехать до будущих версий гораздо ниже, я даже примером readonly locals в статью вынес, но ещё там есть в чём покопаться и о чём рассказать как о потенциальных направлениях развития языка.

Если речь о новых мажорных версиях библиотеки (а делать такое изменение в рамках текущей мажорной версии немного странно) — то тут breaking changes могут служить усилением безопасности. Для первичных конструкторов с большой вероятностью типы и так были спроектированы для использования конструктора базового типа (как в DbContext с options).

А вот обязательные члены меняют принцип инициализации объекта, ещё и требуют нужной области видимости, сейчас даже непонятно, как их хорошо встроить в контейнеры, чтобы те искали и инициализировали required -члены так же из контейнера. Мне сейчас кажется, что required — это больше история про модели и их безопасное использование, так что любой breaking change будет подсвечивать существующую в коде проблему инициализации. И учитывая движение к неизменяемым объектам (с помощью того же init) код уже готов к этому, а init-only свойства достаточно безопасно помечать required.

Это "иногда" касается по большей части пользовательского кода — во внутренней реализации утилитарных библиотек это может использоваться довольно часто. Например, при работе с вебом utf8-литералы заменят большое количество конвертаций в рантайме, а изменения для generic math улучшат разработку новых типов, связанных с математикой.

Некоторые "иногда" значат, что прямо сейчас мало сценариев использования, но за счёт новых фич их может появиться больше. А другие "иногда" и "редко" — это про "очень часто в своей узкой нише", как полуавтоматические свойства для WPF.

При этом исходная простота языка не ломается — в пользовательском коде можно совсем не использовать эти фичи и не знать о них, зато при необходимости есть дополнительная гибкость.

А чего не хвататет для повседневной жизни?

а чем плохо вот это?

public List<string> Names {get;} = new();

Мне нравится val в Kotlin. То что C# берёт или становится похож на Kotlin в этом ничего плохого нету. Я когда попробовал Kotlin после C# сам ловил себя на мысли, что очень много схожего и хотелось бы такую штуку и в C#. Да и разрабы Kotlin'a на выступлениях говорили, что много чего взяли из C# и частично переработали и т.п.