Здравствуйте, Sinix, Вы писали:

S>1. У вас студия запрещена что ли Ваш boilerplate уже лет 8 подставляется автоматом

Мне пофиг, кто и как вставляет юзинги — тут вопрос принципа минималистичности. Если у компилятора достаточно информации для работы, я не должен ему ещё тыкать "возьми там, положи здесь". С таким успехом можно и на ассемблере фигачить — а вдруг C# компилятор неправильно поймёт "add"?
И юзинги не только мешаются в шапке, об них постоянно спотыкаешься в коде — вместо набора fi->выбрал "File" я руками набираю весь класс, после чего студия любезно предлагает добавить нэймспэйс — оно мне надо?

S>2. Это классика проектирования сложных систем: любое новое поведение должно добавляться как opt-in, а не как opt-out.
S>Другими словами, хочешь что-то заиспользовать — будь любезен объявить это явно.

Фигня, всего лишь костные привычки от языков старого формата. Да и "неявного" тут ничего нет — все неизвестные/неоднозначные классы всплывут походу.

S>И да, раскидыванием по библиотекам эта проблема не решается, классика:
S>

S>// Assembly A, references ANode
S>Node Parse(...) { ... }

S>// Assembly B, references BNode
S>Node Parse(...) { ... }

S>// Assembly B, some helper
S>string SomeHelper(...) { ... }
S>

S>В проекте везде используются типы из A, используем хелпер из B. Автореференсы засирают лог сборки несколькими тысячами однотипных ошибок, приятной отладки

Для начала стоит сказать, что и с юзингами отладка одинаковых имён — тот ещё гемор, тут бестолковость _разработчика_, которая к языку не имеет никакого отношения.
Далее, "классика"? Тю, обычный пример из пальца. Разбираем: есть проект C, который юзает две ассембли A и Б, причём в каждой есть класс Узел. Как только мы касаемся Узел в исходнике C/util.cs, сразу попадаем на неоднозначность:

var n = new Node();

...которую тут же легко подправляем:

alias Node = AssemblyB.Node;

var n = new Node();
SomeHelper(n);

Причём alias нужен исключительно для упомянутых в коде классов. Более того — нужный класс Узел может даже быть ВЫВЕДЕН из использования в SomeHelper(n)!
Откровенно, я ещё не видел такого УЖАСНОГО проекта, где два исходника содержат два "разных" Узла и весь этот кошмар юзается в третьем проекте! Ваш высосанный пример только лишний раз доказывает, что проблема сидит в прокладке меж монитором и клавой, нежели в каких-то именах.
Нэймспэйсы нужны — они делают свою работу за кадром, но опускаться до уровня "возьми вот эту либу" — это перекладывать лень разработчиков компилятора на тысячи плеч программистов.

Возможно, проблема не была бы столь надоедливой, если бы филоны из VS team почаще отрывали задницы от кофейных сидений — в студии ДОФИГА всего надо улучшать, а они там иконки перекрашивают! Хотя б собирали для начала имена всех полезных классов, чтоб я не парился с вводом. Но полезность юзингов всё равно остаётся для меня сомнительной.

K>>Про конфликт имён — очевидно и первоклашке, using нужен, но лучше как ключевое слово alias.

S>3. Юзинги в проекте порождают ещё более забавную проблему с включением в проект чужих исходников. Блин, да даже стандартный сценарий "перетаскиваем файл из проекта в проект" после такого пожелания превращается в минное поле.

Ничуть. Проект — это тебе не свалка, в нём не должно быть ИСХОДНИКОВ, которые ты не касаешься. Кажется, я догадываюсь, откуда берутся проекты, компилящиеся по 30 минут — вот-вот, те самые "кучи г-сходников", которые включают наобум.
Нужна либа? Скомпилял дебаг-версию, подключил, забыл. И конфликтов имён никаких.