Там на каждый новый тип требование - унаследоваться от интерфейса, так? В принципе, Вася должен это откуда-то узнать. Так или иначе всё сводится к тому, что при создании нового типа из какой-то специальной группы типов Вася должен где-то прочитать, чему этот тип должен удовлетворять. Либо он должен унаследоваться от специального интерфейса, либо просто в указаниях по написанию этих специальных типов долно быть написано, где нужно добавить код после создания нового типа. В принципе, идея с интерфейсом подходит как наименее затратная и дающая какой-то автоматизм.

Не, не то всё же. Такой подход, как я уже приводил пример, используют для создания костыльного ограничения параметра типа - для числовых типов. Все числовые типы реализуют пачку стандартных интерфейсов

struct Int32 : IComparable, IComparable<Int32>, IConvertible, IEquatable<Int32>, IFormattable

Ставишь ограничение на любой из них и получаешь, что тип должен быть числовой. Правда, любой другой тип, реализующий этот интерфейс, тоже пройдёт, а нам это не нужно. Поэтому и костыль. Всё же лучший вариант был бы, если бы при ограничении параметра типа был бы просто перечень типов, которые возможны. А этого пока нет в Шарпе. Поэтому единственный нормальный выход - пачка перегруженных методов, где разрешённые входные типы параметра явно заданы через каждую перегрузку.