Всё-таки к разметке ответов есть вопросы...

Это всё Хаббл виноват. Избаловал людей картинками.

А вообще JWST же не JPEG-и на землю льёт. Прежде чем будет получено изображение, идёт внушительная математическая обработка сырых данных. Ну будет в данных небольшое увеличение энергии вне основного пика изображения и чуть-чуть ухудшится угловое разрешение, которое визуально заметно не будет.

Ну, чисто в теории можно, есть еще старенькие проекты, использующие файловую систему, идею которых можно еще увидеть в университетских лабораторных по сей день.

Какое сильное, но ничем не обоснованное, утверждение. В десктопе большинство софта будет работать без БД, будь то офисный пакет, смотрелки всяких файлов, файловый менеджер, архиваторы, VPN клиент... Имя им легион.

Вы можете продолжить корректную работу с полученными данными?

Если ответ "нет" - то бросать исключение.

OCP можно и в функциональном стиле сделать, и в процедурном, и в каком угодно.

Он не про наследование, а про расширение без модификации, то есть о наличии (закладывании) большого количества степеней свободы для кастомизации при расширении без модификации исходного модуля.

На плюсах это может быть достаточное количество шаблонных параметров или трейтов. В функциональных языках на каждый чих принимать внешние функции (желательно с поведением по умолчанию). Аспектно-ориентированное программирование - это тоже возможная реализация OCP. Ну и так далее.

А тут как раз нет противоречий.

Бюджет будет на следующий год - заложите зарплату команды на следующий год плюс 20...30% запаса. За этот год возьмите обязательства понять затраты на следующий или на пару следующих лет. За этот год привяжите платящего к проекту, и дальше факт того, то проект уже есть и что-то по нему делается, не позволит не профинансировать его дальше.

Многих ошибок можно было бы избежать, если бы предусловия проверялись бы как можно раньше и как можно проще...

Разбить проверки в Issue 3 на два, в 12 проверить каждое отдельно, в 7 проверить последовательно...

В начале метода в блоке предусловий выходов должно быть столько, сколько нужно, не надо упарываться и пытаться делать только один.

Не как замечание, но как подсказка будущим поколениям: в Issue 6 можно было бы переписать код с использованием Pattern matching:
Вместо выражения вида

var userId = folders.FirstOrDefault()?.UserId ??
             ciphers.FirstOrDefault()?.UserId;

if (userId.HasValue)
{
   Consume(userId.Value)
}

Написать

if (folders.FirstOrDefault()?.UserId ?? 
    ciphers.FirstOrDefault()?.UserId 
    is {} userId)
{
  Consume(userId);
};

И больше не иметь дела с nullable int.

Агрегация -- это про хранение (поля объекта)

Внедрение -- это про получение (аргументы конструктора)

В Go обещают завести generic-и. Он куда движется? А как насчёт Rust-а? А Scala?

OTUS покажите вашим переводчикам где можно хотя бы актуальные статьи брать...

public ref T this[int index] => ref rawData[index];

Ну, если под реактивностью подразумевать распространение изменений через уведомление (push-модель), то наверное сову на глобус соответствующей формы натянуть возможно.

А Ваше исходное предложение к какой версии относится? Может сначала стоит сделать апгрейд до актуальной версии языка?

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

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

required будет иметь проблемы с сериализаторами/десериализаторами.

И надо понимать, что половина написанного здесь может не доехать не только до C# 11, но и вообще до языка.

Флаг, под которым самая большая страна мира идёт в каменный век?

Забавно, что Random.Shared имеет под капотам ThreadStatic-поле, то бишь нифига он не шарится между потоками.

Random ObtainRandom() => random ??= new Random(Guid.NewGuid().GetHashCode());

Можно вот так сделать...