insighter

Вам все коллекции необходимо создать

public ICollection Tanks { get; set; } = new List<Tank>;

и так далее..

Отмечу решением этот вариант.
Если нет входа в учетную запись Гугла, Хром не предлагает сгенерировать новый пароль. Это я проверил. Но при этом он разрешает сохранить введенный пароль.
Если есть вход в учетную запись, все генерируется и сохраняется.

Все хранить в стеке невозможно для обычных программ.
Все хранить в куче реально (достаточно упаковывать все valued-переменные), но очень и очень не оптимально. Работа со стеком гораздо быстрее, для работы с ним есть специализированные регистры процессора, а для того чтобы обратится к участку произвольной памяти компьютера даже на низком уровне надо сделать много операций. И очищается стек моментально, никаких сборщиков мусора не нужно.

мне передать 2 массива

Откуда передать, где они создаются эти массивы? Если в форме, то они и так доступны.

Если у тебя обработчик события находится в другом объекте (не метод формы), тогда до формы можно добраться через sender:

... (object sender, ...)
{
    var form = (Form)((ButtonExtendet)sender).Parent;
    form ... доступны все свойства и методы формы
}

id студента (судя по вашему примеру) - это комбинация полей name + surname
поиск по такому id будет следующий:

var searchName = "значение для поиска";
var searchSurname = "значение для поиска";
var foundedStudent = students.Find(student => student.name == searchName && student.surname == searchSurnname);
if (foundedStudent != null){
  foundedStudent ... меняйте как хотите
}

Ошибка того, что куки были удалены не полностью, а только одна "AspNETCore.Cookies". Руками надо удалить остальные две "ai_session", "ai_user".

ASP.Core при попытке продления куки выдавала внутреннюю ошибку.

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

public interface ITalkingShape
{
string SayAboutYourself();
}

public class Square : ITalkingShape
{
  string SayAboutYourself()
  {
    return $"figure is square. ■\nIts area is {Shape.GetArea(shape)}.\nIts perimeter is {Shape.GetPerimeter(shape)}.\n\n";
  }
}

public static void Display(ITalkingShape shape)
        { 
Console.WriteLine(shape.SayAboutYourself())
}

Думаю никаких паттернов вам не надо.

Глянул на пэт-проект, который сейчас пишу - 5тыс строк + 1тыс тестов, и если честно, ощущение, что проект даже не начал ещё толком писать.

Конечно архитектура - это ключевой вопрос. Не бойтесь рефакторить код в пользу хорошей архитектуры.
Если надо будет выбрать одно - переписать неэффективный алгоритм или переделать структуру проекта, я всегда выберу второе. Плохая архитектура похоронит проект, а плохой алгоритм или плохую реализацию функционала всегда можно переделать потом пока совсем не прижмет.
Конечно также нужны тесты хотя бы на ключевые штуки.

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

PS хотел бы ещё важное добавить, архитектурными делами надо заниматься не наскоками. Тут как back-end <-> front-end, мне например сложно перескакивать с одного на другое в течение дня, большие задачи делаю только одно, или back или front.
С архитектурой также надо поступать. Потому, что сложно переключать мышление с глобальных абстракций на детали реализации.

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

var leader = new Func<Entity>(() => { var lui =ui as UI; var l = lui.leader; return (l == null || lui.b_leader_dead|| !l.isValid) ? null : l.Owner;  })();

Спасибо Антон Барышев за решение, нужно добавить опцию new()

public class RefferedObjectModel<TDataObject> : Model<TDataObject>
    where TDataObject : ReferredObject, new()

Ответ нашел сам.
При сравнении старого и нового DOM, React сравнивает поле key у существующего и нового объекта, если значения
полей совпадают, то новый объект отбрасывается, иначе старый объект будет уничтожен и полностью замещен новым. Конечно же сравнение ключей лишь малая часть общего алгоритма согласования.

Моем случае, компоненты, которые отображаются в табах могут быть разных типов, а чаще всего только так и есть.
Поэтому React не использует сравнение через key и удаляет оставшиеся закладки (хотя! почему то, если создать
вкладки одного типа, они все равно удалятся)

Решение найдено в использовании компонента Fragment с суррогатным ключом key

Генерация ключа:

const [keyGenValue, setKeyGenValue] = useState(1);
    ...
    // генерим новое значение при открытии новой вкладки
    setKeyGenValue(() => {
        return keyGenValue + 1;
    });

Генерация рендера:

<div className='workspace'>
    {views.map(
        (view, index) =>
        <Fragment key={view.key}>
            <div hidden={view !== selectedView}>
                    <h4>{view.caption}</h4>
                    <div>{buildView(view.name)}</div>
            </div>
        </Fragment>
    )}
</div>