По ходу дела вспоминаются предлагаемые здесь на форуме решения для "STL". Любопытно это решение:
https://forum.oberoncore.ru/viewtopic.php?f=47&t=6234

, которое, по сути то, есть обман системы типизации благодаря использованию средств runtime-рефлексии из-за необходимости доступа из базового типа к полям, которые определяются в потомках (расширениях) -- в системе типов нет никакого понятия что-то вроде абстрактных полей, контракт типов молчит о таких приёмах и, фактически, в итоге вводит в заблуждение (особенно таких как я, плотно незнакомых с рефлексией. И, к слову, обычно "report-ы о языке" не содержат сведений о средствах метаинформации как важного языкового аспекта).
В целом, средства рефлексии подталкивают (или, как минимум, не предотвращают) к стилю "ruby on rails" -- это когда активно используются "устные" соглашения вида "Container.FindBySomeID(value)", где у некоторого контейнера данных вызывается метод с определенным именем задаваемого формата, в частности: найти элемент, у которого поле SomeID равно такому-то значению. Т.е. в runtime форматируемые имена методов и прочих элементов языковых структур приобретают определенные роли (возможна и динамическая компиляция/создание элементов, если языковая среда позволяет, или каким-то способом динамически устанавливаются/реализуются роли в элементах), о ролях и форматах "договариваются" вне системы типизации. С одной стороны якобы простота и удобство, с другой "проверка контрактов" полностью в runtime (самостоятельная, т.е. задаваемая разработчиками) с соответствующими последствиями (при критической массе таких договорённостей (которых ещё нужно знать) разбираться уже трудно, тем более когда структура "договоров" возникает в runtime).