В твоем примере ниже Б2 - как раз идеально подходит для GAC.

As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required.

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

Установка/Удаление/Проверка, права админа и пр. дополнительная морока. Потом не забываем, это чисто в примере 1 либа, а на самом деле их гораздо больше. Причем, то что нужно для одного проекта, совсем не нужно для другого. Что будет на компе разработчика в GACе после полугода

Ну а дальше надо ввести простое правило - верхнии уровни используют только релизнутые компоненты. ...а работоспособность компоненты гарантируется процессом релиза

Есть такой волшебный процесс?

Так что нужно отделять разработку компонент от разработки продуктов

А еще отделять разработку "мелких" компонент от более "крупных".

Также как нельзя гонять 100500 тестов при каждом изменении комментариев

Кто будет постоянно объяснять CI что менялись чисто комменты и чтобы он замолк на ночь в этот раз. А как насчет того, что "незначительные изменения" могут привести к сбоям в других системах.... А как насчёт того, что оборудование есть только у клиента и нормальные тесты вообще нельзя провести?

тут надо уже искать решение для каждого конкретного случая

Как раз то и хочется найти решение для всех случаев. Ну или хотя бы для большинства стандартных. При релизе "думать" низзя. Особенно когда у клиентов непрерывное производство.

Именно это он и умеет, но есть одна маленькая проблемка - пользователь их должнен менять через GUI.---Почему это проблемка?

Потому что плагин должен иметь GUI. А плагины можно пользовать из Winforms или WPF, а при тестах и консолью попользоваться.