Под g++ и clang тоже компилится

В чём дороговизна? Количество классов? А чем это мешает?
Например, в использовании QTreeView разве мешает его наследование от QTreeView, QAbstractItemView, QAbstractScrollArea, QFrame, QWidget, QObject, QPaintDevice?

Я не понял, что здесь написано

Пускай расходятся, я не против. Функционал будет расширяться невиртуальными методами.
Виртуал здесь выделен по той причине, что из шапки видно, что ТС хочет иметь некий метод do_Something в каждом экземпляре менеджера. Также видно, что он хочет возвращать указатели на менеджеров. Я предположил, что возможно он, захочет ещё держать менеджеров в неком контейнере и в цикле вызывать у каждого do_Something.

Вы с QPaintDevice знакомились от и до перед тем как использовать QWidget? Также если я хочу досконально знакомиться с классом, то я быстрее познакомлюсь с классом в 50 строк, чем с монстром в 1000.

Опять не понимаю.

Потом тупо исправить ошибку в 9 из них и тупо забыть исправить в 10. Затем понять, что надо немножко расширить функционал и снова тупо копипастить. А потом мы в менеджере №3 захотим метод сортировки наоборот, а в менеджере 8 возможность общаться с себе подобными. И, конечно, будет куда проще разобраться в этих 10 классах, чем в одном шаблоне.

Чем же она другая? Никто не запрещает пользоваться классом ElementManager не зная внутреннего строения AbstractManager. Точно также, никто не запрещает постепенно осваивать AbstractManager.

Конечно можно. А ещё можно обойтись процедурным программированием в едином main.cpp или ассемблером.
Повторю, что на мой взгляд, понять устройство маленького класса значительно проще. Помимо этого здесь есть преимущество в скорости компиляции. Не всегда требуется инклудом тащить толстый класс (а может и не один). Достаточно взять интерфейс и через него вызывать необходимые виртуальные методы. Мне кажется, что вам эти преимущества уже не один раз разъясняли и вы вновь занимаетесь флудом в сторонней теме.

Потому что ТС писал
Наверняка класс будет претерпевать расширение.

А про классы без использования шаблонов вы случаем не скажете того же самого?

2 kuzulis, а вы не рассматривали вариант использования QMap<IdType, ValueType> ?

Да, может быть и так

А здесь неясно. Если 10 совершенно независимых классов - у меня никаких проблем с сортировкой наоборот в менеджере №3. А вот если укладывать их в общую конструкцию - придется пыхтеть с обобщением.

Не исключено что и легче. Напр можно записать

C++ (Qt)
manager.addMyObject();
// вместо безликого 
manager.addElement();
 

И это может оказаться лучше (или приятнее) экономии с template

Ну это вряд ли  

Не кипятитесь Я же не говорю что предложенное Вами плохо. Просто не все так однозначно, есть масса переходов и других цветов кроме "черного и белого". Если менеджеры хранят разные классы, то очень может быть что ничего "особо общего" у них и не найдется

ИМХО, видится такая реализация:

- менеджер - елементы: независимо от типов обоих, уже есть что-то общее (добавить/удалить и т.п.), поэтому делаются базовые нешаблонные классы Manager, Element. В этих классах декларируются сигналы added(Element*)/removed(Element*) и т.п. Естественно, для обеспечения полиморфизма здесь используются только указатели Manager*, Element* (или смарт-указатели).

- далее для типобезопасности используются тонкие шаблонные обертки, выполняющие downcast.

В результате, нет "раздутия" кода из-за шаблонов, и есть типобезопасность.