вроде бы для любого компилятора достаточно дальше сравнить type_handle и C<P1<2,4>>::name() на равенство как указатели

Обновил то как это должно использоваться

==================
FRAMEWORK

class PackageBase
{
    virtual size_t size() = 0;
    virtual size_t weight() = 0;
}

Class C {
     PackageBase p_;

    set_package(PackageBase &&p);
    is_package(const PackageBase &p); // deep copy?!
}

===================
USAGE

template<std::size_t P, std::size_t N>
class P1 : public  PackageBase {…}

template<typename T>
class P2 : public  PackageBase {…}

C c;
c.set_package(std::move(P<2, 5>{weight = 5}));
c.is_package(P<2, 5>{weight = 5});  // Создавать объект не надо. Достаточно сравнить тип

А нет ли возможности разделить constexpr и не-constexpr конструктор?

С одинаковыми аргументами

    static char * name() {
        static constexpr char* id = __FUNCTION__;
        return id;
    }

вроде вот так надежнее

struct CBase {
   virtual const char* type_handle() const = 0;
};
template <typename T>
class C : public CBase {
    static constexpr char * name() {
         return __FUNCTION__;
    }
    const char* type_handle() const override {
        return name();
    }
};

Блин, не въезжаю… можешь показать пример использования? Как мы создаем С в системе?

Да как хотим, C<P1>{ /*forward to P1 ctor*/ }; уже работает. Полиморфное C это CBase&

Ну т.е. мы создаем кучу С под каждый тип, так?

Под каждый PackageBase, да. При этом никто нас не заставляет, скажем, не писать функции в CBase

Тут есть момент про который вскольз упомянул. В контейнере С есть функция c.exec() который вызывается из прерывания. Прерывания частый (по таймеру). т.е. у нас есть глобальный объект из которого мы вызываем в прерывании один метод постоянно. Это помимо остального

Ну т.е. фактически как я это вижу, мы не можем насоздавать разных объектов контейнеров под каждый тип.

Если C в вашей версии хранит полиморфный PackageBase, сам по себе C не может не быть полиморфен

ну мы можем хранить variant, так?

variant ничего не изменит в целом

это будет тот же самый полиморфный C, который спасся от аллокации при хранении полиморфного PackageBase (и получил за это врожденный архитектурный дефект, объявив полиморфную сущность как ADT)

Вызов exec() задействует PackageBase?

ага. как раз в этом методе вызываются size и weight

Если да, то в какой-то момент он узнал фактический тип PackageBase.

Я тут подумал. теоретически можно организовать пул из которого аллоцировать память. и тогда хранить просто указатель. Может это поможет?

Этого уже в принципе нельзя избежать - виртуальный вызов тут будет до тех пор, пока вы не запишете C<P1>::exec неполиморфно вектором прерывания