Роман

Вот вам перевод (часть первая, а всего там шесть частей) фундаменнтальной статьи по async/await одного из разрабочиков .NET в Microsoft (а именно - Stephen Toub).
Читайте и просвещайтесь.

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

• компилятор преобразует код асинхронного метода до неузнаваемости, в ту самую "машину состояний": класс, в котором есть метод, ее реализующий, и есть поля для данных, как нужных для работы самой машины состояний (в частности - для хранения состояния), так и для хранения локальных переменных исходного метода (да-да, в стеке они не хранятся);
  
• каждый кусок исходного метода - начальный, между двумя await и завершающий - преобразуется в отдельный кусок метода машины состояний, выполняемый, когда выполнение машины состояний возобновляется в определенном состоянии; этот код производит действия, определенные в этом куске метода, и либо меняет состояние на новое значение и переходит к ожиданию (там, где в исходном асинхронном методе написан оператор await), либо завершает выполнение метода машины состояний;
  
• для выполнения перехода к ожиданию используется объект awaiter'а, получаемый методом GetAwaiter() операнда операции await;
  
• перед переходом к ожиданию проверяется возможно продолжение без ожидания, если это возможно (метод IsCompleted() awaiter'а возвращает true), то ожидания не происходит, а возобновляется выполнение машины состояний уже для нового состояния;
  
• запуск ожидания происходит во внешнем относительно асинхронного метода коде - в объекте awaiter'а;
  
• и при завершении метода машины состояний, и при запуске ожидания метод машины состояний возвращает управление в код, который вызвал в этот раз метод машины состояний (для одного вызова асинхронного метода вызовов метода машины состояний может быть много, см. дальше);
  
• первый возврат из метода машины состояний происходит в вызывающий метод, он возвращает объект задачи, позволяющий отследить в вызывающем методе завершение работы машины состояний ( и тут есть нюанс, связанный с возвращением ValueTask, а не Task);
  
• при окончательном (а не при запусе ожидания) выходе из метода машины состояний этот возвращенный объект задачи завершается;
  
• после завершения ожидания метод машины состояний вновь вызывается: в типичном случае - в свободном потоке из пула потоков, но возможны варианты (какие - курить тему Synchronization Context); и он продолжает свое выполнение для нового состояния
  

Это - максимально урезанное описание работы асинхронного метода.
Если вы смогли из этого описания понять ответ на ваш первый вопрос - хорошо. Если нет - читайте статьи(ссылка выше), или книги (лично я рекомендую главу про асинхронные меотоды из книги Рихтера "CLR via C#").
Касательно второго вопроса. Задачи, выполнение которых ожидает асинхронный метод, будут выполняться совершенно параллельно, каждая - в своем потоке из пула, возможно - на разных ядрах/процессорах). А асинхронный метод в это время не будет выполняться совсем: поток в котором он выполнялся, будет дальше выполнять код после его вызова в вызвавшем его методе (или код, возвращий поток в пул, если это был вызов машины состояний после ожидания). А после завершения обеих этих задач выполнение метода машины состояний, в который был преобразован асинхроннный метод, будет возобновлено и задача, которую возвратил асинхронный метод, будет завершена.

Переключите масштабирование экрана в 100% и проверьте код - всё должно работать как было. В WPF накрутили свои фичи вокруг масштабирования и теперь даже банальное размещение окна в нужной позиции и нужного размера - это цирк с конями на велосипедах, жонглирующими хомяками-акробатами. К сожалению под рукой нет кода, но он легко гуглится по ключевым словам типа WPF DPI real cursor position / real window position. Там надо для каждого экрана получать DPI и использовать его для получения WPF координат или реальных координат на экране.

RTFM: System.Windows.Controls -> ListView

• Свойство SelectedItem
  
• Событие SelectionChanged
  

На событие вешаете свой код с нужными вам действиями.

Как создавать потокобезопасные вызовы к элементам управления Windows Forms: https://learn.microsoft.com/ru-ru/dotnet/desktop/w...

void FormAMethod()
{
    if (formB.InvokeRequired)
    {
        formB.Invoke( () => formB.Text = "data" );
    } 
    else
    {
       formB.Text = "data";
    }
}

Только стандартный компилятор МС. Ибо WinForms - это по сути обёртка над древним легаси кодом и попытка сделать удобный визуальный конструктор форм и которая сама по-себе уже стала легаси. А, ну и в проектах WinForms всё равно приходится использовать костыли для тех или иных вещей. Вы думаете кто-то будет делать и поддерживать C# компилятор для дважды древнего легаси проекта МС? Даже если найдётся какой-то другой компилятор - с вероятностью 95-99% вообще любой проект WinForms придётся долго и мучительно пичкать костылями, чтобы оно просто хотя бы собралось. Да и потом еще надо будет заставить это всё не просто работать, а правильно работало. Даже искать решение нет смысла - вероятность проблем практически 100%.

1. Пишете нужный класс с нужными данными: Как правильно описать класс для библиотеки Newtonsoft.Json C#?
   
2. Открываете ман Newtonsoft.json в разделе конвертеров: https://www.newtonsoft.com/json/help/html/CustomJs... и далее в гугле.
   
3. Пишете свой конвертер
   
4. Радуетесь результату
   

Данные погут меняться только от действий пользователя. Так что включите режим read only пока идет сохранение и никто ничего поменять не сможет

Перегрузка индексатора

public class Foo : Dictionary<string, int>
{
    public new int this[string key]
    {
        get => this.GetValueOrDefault(key);
        set => base[key] = value;
    }
}

Foo f = [];
string k = "key";
Console.WriteLine($"Value not set: {f[k]}");
f[k]++;
Console.WriteLine($"Value ++: {f[k]}");
f[k]++;
Console.WriteLine($"Value ++: {f[k]}");
f[k]--;
Console.WriteLine($"Value --: {f[k]}");

Value not set: 0
Value ++: 1
Value ++: 2
Value --: 1

int a { get; }
Свойство только для чтения: можно записать только в конструкторе или инициализаторе, а в методах класса и других способах нельзя изменить.

int a { get; private set; }
Свойство только для чтения снаружи класса: можно записать только внутри класса - в конструкторе, методе и в остальных способах.

Ну сборка - это то что в dll-файле, да.

Где ты прочитал о статических и динамических я не знаю, по тому загуглил сам.

Статическая сборка - это такая, сборка, которая сохранена как dll-файл.
Динамическая - которая создана при помощи System.Reflection.Emit и существует только в рантайме.

Условие цикла for написано не верно:

// for(int i = 0; i >= _inventory.Length; i++)
for(int i = 0; i < _inventory.Length; i++)

// Или если _inventory изначально может быть пуст, а значит и перебирать там нечего.
for(int i = 0; i <= _inventory.Length; i++)

Ты можешь создать сборку (грубо говоря, проект/.csproj), которая называется Service.Domain, но все классы там будут в неймспейсе (пр-ве имен) Another.Namespace
Т.е. название проекта не накладывает ограничений на названия пр-в имен, которые в нем хранятся.

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

Использовать стандартные паттерны типа MVC и MVVM. Для большинства приложений этого достаточно. Если приложение более сложное, то оно делится на компоненты в виде, опять же, стандартных библиотек и приложения/приложений.