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

S>Потом возвращаться и дописывать гораздо эффективнее:
S>- это приходится делать не всегда
S>- когда приходится это делать, у вас уже есть понимание предполагаемого сценария использования, поэтому вы можете сделать более оптимальный код

Дописать это сейчас — 5 минут нудной, рутинной работы, т.к. я в контексте и знаю как всё работает.
Если не понадобится — я потерял 5 минут времени, бывает.
Если же понадобится через полгода, то я потрачу полчаса, а то и несколько часов.
Потому что, сначала нужно разобраться во всех этих наследованиях, найти тот класс, где есть нужный конструктор, потом по всей иерархии его пробросить.
Это ещё при условии, что кто-то вообще задумается, что возможно где-то в недрах есть нужный конструктор, а не надстроит что-то сверху через фабрики или ещё какие-нибудь отличные паттерны.

S>Ну, и я всё ещё не увидел никакого примера, в котором вам бы реально потребовалось выставлять наружу в вашем наследнике KeyedCollection конструктор с IEqualityComparer, а без этого у вас бы получился неоптимальный код.

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