ты можешь это легко проверить, TypeInfo(T) и посмотреть какой реально тип

нет. это  очень частный случай. причем другой.

каким образом их этого поля может вызываться левый метод? которого в типе нет?

но мы же выяснили, что это баг.
убедись, что T имеет правильный типа в рантайме

и что это даст? даже если имеет? метод-то правильный не вызовешь

ну дак я о чем и говорю - одна проблема есть.
почему ставить крест на всех женериках?
ну и достаточно не допускать ошибок проектирования классов 🙂

ок, а как правильно спроектировать? ну для случая сортировки коллекции, например

конкретно в твоем изначальном примере сделать метод виртуальным

т.е. "правильно" это не использовать женерики. и иметь при сортировке вызов виртуального метода на каждое сравнение?

правильно - это не иметь в иерархии классов одноименные невиртуальные методы.
я говорил только об этом.

по поводу сравнения - надо использовать компараторы. другого варианта нет.
может быть было бы неплохо иметь такой констрейнт, чтобы обойтись без компаратора для стандартный value types, но его нет.
обидно, но не страшно. всегда есть  TComparer<T>.Default

а как же производительность? ну ее?

нет конечно, не "ну ее". и я выше об этом написал - было бы приятно иметь такой бонус.

но, возвращаясь, к твоему изначальному утверждению, что такие женерики не нужны. разве это так? они есть, они работают, пускай даже есть один баг и не самый оптимальный способ сравнения.

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

повторюсь, у тебя специфичный случай, хотя это и не оправдывает наличие бага.
если использовать delphi way, то виртуальных методов не будет, тк будут вызовы методов  интерфейса (обычные методы, не вирт), как для сравнения, так и для подсчета хэша мапы

А где почитать про "виртуальные методы женериков"? Такое интересное извращение, а я с ним не знаком.

И про компаратор женериков. заодно

Интересно, кто такую дикую дичь придумал?

Чем тебе компаратор не угодил?

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

Он сделан в виде интерфейса с женериком? Я потрясен.