Почему std :: type_info полиморфен?

Есть ли причина, по которой std :: type_info указан как полиморфный? Деструктор указан как виртуальный (и есть комментарий к эффекту «чтобы он был полиморфным» в Дизайн и эволюция C ++). Я не вижу веской причины, почему. У меня нет конкретного варианта использования, мне просто было интересно, было ли это когда-либо объяснение или история.

Вот некоторые идеи, которые я придумал и отверг:

1. Это точка расширения - реализации могут определять подклассы, а затем программы могут попытаться dynamic_cast a std :: type_info к другому производному типу, определяемому реализацией. Возможно, это причина, но кажется, что реализациям так же легко добавить член, определенный реализацией, который, возможно, может быть виртуальным. Программы, желающие проверить наличие этих расширений, в любом случае обязательно будут непереносимыми.
2. Это необходимо для обеспечения правильного уничтожения производных типов при удалении базового указателя. Но стандартных производных типов нет, пользователи не могут определять полезные производные типы, потому что type_info не имеет стандартных общедоступных конструкторов, и поэтому delete в указателе type_info никогда не бывает одновременно легальным и переносимым. А производные типы бесполезны, потому что они не могут быть сконструированы - единственное, что я знаю для таких неконструируемых производных типов, - это реализация таких вещей, как свойство типа is_polymorphic .
3. Это оставляет открытой возможность метаклассов с настраиваемыми типами - каждый реальный полиморфный класс A получит производный " t полиморфный. Но учитывая, что нет стандартного производного типа и нет других классов в стандартной иерархии, для которых можно было бы разумно попробовать перекрестное приведение, возникает вопрос: что? Можно ли использовать такие выражения, как typeid (std :: type_info) == typeid (typeid (A)) ?
4. Это потому, что разработчики создадут свой собственный частный производный тип (как я полагаю, GCC делает ). Но зачем это указывать? Даже если деструктор не был указан как виртуальный, и разработчик решил, что это должно быть, конечно, эта реализация могла бы объявить его виртуальным, потому что он не изменяет набор разрешенных операций для type_info , поэтому переносимый программа не заметит разницы.
5. Это как-то связано с сосуществующими компиляторами с частично совместимыми ABI, возможно в результате динамического связывания. Возможно, разработчики могли бы распознать свой собственный подкласс type_info (в отличие от подкласса от другого поставщика) переносимым способом, если бы type_info гарантированно был виртуальным.

Последний - подкласс наиболее правдоподобно на данный момент для меня, но довольно слабо.