Уже какой раз пытаюсь написать ответ, постоянно вытираю - нету полного понимания. Остановился вот на чем:
Будет ошибка, в any_arr.set_index(1, obj_int); мы вместо указателя на объект-предок T, даем указатель на его наследника, который занимает больший (в любом случае другой) размер в памяти. Типизированный указатель - это только адрес первого байта данных . Как мы узнаем, где находится его конец? Адрес + sizeof(тип указателя). А так как вместо ожидаемого типа, мы даем другой, то должна произойти "обрезание" передаваемого объекта, т.е. укаатель на него будет "не полным" . И потом typeof скопирует себе не весь объект, а только его часть и при попытки обратится к объекту, чтобы узнать его VMT, получим ошибку. ИМХО. Хотя...

Дело все в том, что функция TypeOf ничего никуда не копирует... если бы она работала так, как ты написал - в нем бы вообще смысла не было: это была бы просто функция, позволяющая в Compile-Time определить тип объекта... А зачем мне тогда привязываться к VMT? Дело все в том, что TypeOf возвращает адрес VMT для объекта (или типа, в RunTime уже созданы все таблицы причем в единственном экземпляре для каждого объектного типа, что позволяет программе определить, где БУДЕТ находиться VMT экземпляра объекта, когда он будет создан)...

А оно нам надо?

Руководство по языку B.Pascal 7 & Objects/LR -> Таблица виртуальных методов
, так что же получается? Если объектный тип имеет таблицу виртуальных методов, то у всех его потомков тоже гарантированно будут свои таблицы, так? Таблица создается всегда, кстати... Даже если не вызвать конструктор. Конструктор - он ведь только устанавливает в экземпляре объекта ссылку на VMT, поэтому, кстати, если НЕ вызвать конструктор, а вызвать виртуальный метод - система или зависнет, или тебя просто выбросит в General Protection Fault (поскольку ты не в чистом DOS-е). Причина - программа НЕ ЗНАЕТ, где расположена VMT, но таблица-то есть...

А если таблица есть и у предка, и у потомка, то логично будет предположить, что адреса хранятся в одном и том же месте? Так зачем КОНЕЦ объекта? Компилятору важно правильно добраться до того места, где хранится адрес, а это место гарантированно существует уже в предке - следовательно, все нормально...

Так что, твои рассуждения не верны... ТАМ где ты думаешь, ошибки не будет...

procedure TArr.set_index(i: integer; p: PT);
begin if i <= maxSize then arr[i] := p; end;

при такой передаче p (при помощи указателя, да еще и без var ) приведение типов не осуществляется. в итоге у нас будет указатель на класс-наследник (тип у него будет наследниковский, то есть TFloat), однако поля и методы, введенные в наследнике, доступны не будут (ну это нам и не нужно в данной программе)....
Итак, в результате мы получим странный массив, в котором один элемент - указатель на TFloat, один на TInt, а остальные - на нечто непонятное. То есть тип этого непонятного определяться будет, но он не совпадет ни с типом T, ни с типами его наследников.
аналогичная ситуация и с вызовом для new(PT) - экземпляра нет, VMT не создана. Определить-то тип определим, но какой.....
Получим count=0
А вот если вызвать

any_arr.count_each(obj_float);

- получим count=1.

Значит, так... Ошибка (вернее, недочет, который выявится при некоторых установках IDE Турбо-Паскаля, ну, и естественно, в любом 32-битном компиляторе) номер один:

  for i := 1 to maxSize do
    if typeof(arr[ i ]^) = typeof(p^) then inc(count); { <--- Здесь ... }

А именно - в попытке разыменования нулевого указателя (большинство компиляторов все-таки инициализируют все элементы arr nil-ом, потому, что эта переменная размещается не в стеке, а в куче)

исправляется очень просто:

  for i := 1 to maxSize do
    if (arr[ i ] <> nil) and (typeof(arr[ i ]^) = typeof(p^)) then inc(count);

Второе:

Цитата(мисс_граффити: попытка объяснить происходящее)

в результате мы получим странный массив, в котором один элемент - указатель на TFloat, один на TInt, а остальные - на нечто непонятное.

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

[i]Вот, кстати, еще одна причина при создании класса явно инициализировать все его члены либо сразу нужными значениями, либо нулем (или соответствующим ему значением для типа поля): если бы все было проинициализировано нулями, программа вылетела бы независимо от ключей компиляции, а это лучше, чем выдывать похожий на правду результат, а при определенных условиях начать сбоить...

Третье: для того, чтобы процедура count_each работала корректно (выдавала правильный результат), достаточно передать в нее указатель на объект, с инициализированной VMT, т.е. или так, как показала мисс_граффити - передать один из ранее использованных указателей, для которого вызывался Create, или

any_arr.count_each(new(PTfloat, create));

Но, если кто-то подумал, что это - все... Нет... Есть еще кое-что... memory leaks, в связи с чем

Добавляем явное "засовывание" в arr[3] указателя на T:

var
  TT: ^T;
  obj_int: ^Tint;
  obj_float: ^Tfloat;
  any_arr: TArr;
begin
  any_arr.init;
  obj_int := new(PTint);
  obj_int^.Create;
  obj_int^.value := 3;
  any_arr.set_index(1, obj_int);
  obj_float := new(PTfloat);
  obj_float^.create;
  obj_float^.value := 3.5;
  any_arr.set_index(2, obj_float);
  TT:=new(PT);
  TT^.create;
  any_arr.set_index(3,TT);

А теперь делаем Evaluate:
typeof(any_arr.arr[1]^) Ptr(DSeg,$A)
typeof(any_arr.arr[2]^) Ptr(DSeg,$12)
typeof(any_arr.arr[3]^) Ptr(DSeg,$2)
typeof(any_arr.arr[4]^) Ptr(DSeg,$1068)
Почему так?
И разве сравниваться будут не эти значения?