Для чего? Чтобы каждый кому не лень кидал туда свои либы

Именно так. Ну не просто либы, а расшаренные либы. В твоем примере ниже Б2 - как раз идеально подходит для GAC.

Если даже изменить коммент в Б2 студия перестроит всё и приложение и плагин1 и плагин2. Хотя даже если просто заменить Б2, то согласно Black-box testing нужно перепроверить полную цепочку. Мы ведь "не знаем", что менялось в Б2.

Ну так ты раздели все это на 4 независимых компоненты: приложение, плагин1, плагин2 и Б2. У тебя получится 2 уровня - на нижнем уровне Б2, на верхнем приложение и плагины. Ну а дальше надо ввести простое правило - верхнии уровни используют только релизнутые компоненты. Таким образом Б2 никогда не будет перекомпилироваться, а работоспособность компоненты гарантируется процессом релиза.

Да, я понимаю, что такая перестройка сделает разработку более долгой. И да, я понимаю, что начальство будет возражать :) Но я не знаю другого более или менее надежного способа. Если собирать все мнесте, то косяки будут всплывать постоянно. Так что нужно отделять разработку компонент от разработки продуктов.

Мы ведь "не знаем", что менялось в Б2.

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

Ну и кроме того, в большом проекте совместимость иногда приходится нарушать.

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

И еще - вы с "подписанными либами" работали?

В GAC неподписанным нельзя :)

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

Почему это проблемка?

Так в тот то и смысл, чтобы прога ничего не знала о плагинах, кинул что новое - взяла и подхватила или сказала сорри, слишком молод.

Помню, мы делали расширение для FinalBuilder'а, так при установке нашего расширения мы патчили ему app.config :D Впрочем, можно, это не самое лучшее решение :D