Если вместо QImage использовать QVariant, то возможен динамический полиморфизм.

Вариант и эни не то, что нужно, они не дают корову.
Написать такой указатель можно (2мя способами - через наследование от интерфейса с методом clone() либо через мета-объектную систему, выцеплять конструктор копирования).
Не очень понятно, правда, какую задачу решает данный указатель.
Корова эмулирует value-based типы (которые копируются на стеке).
Шаред-птр и юник-птр (и любой другой птр) хранят указатели на уникальный объект (который не должен копироваться).
В чем смысл клонировать объект?

Upd: ну только могу придумать когда внешне это всё тот же value-based, а внутри полиморфная приватная дата (например, зависит от платформы, хз). Это делается через пару QSharedDataPointer на дату + std::unique_ptr на полиморфную часть в этой дате.

Задача иметь обычный ф-ционал указателя (может указывать как на базовый тип так и на порожденный) но "одетый" в удобную оболочку вумного указателя. Хранить "все на свете" планов не было

Кажется, эта задача решается с помощью python

Ещё раз - какую задачу вы решаете?
COW решает задачу дешевого копирования объектов на стеке. То, что там внутри указатель мы знать не должны (просто абстракция весьма дырявая, поэтому приходиться знать как оно "под капотом").
shared_ptr решает задачу раздельного владения уникальным объектом.
unique_ptr решает задачу уникального владения уникальным объектом.
Что вы хотите сделать? Пример с куимаджем нерелевантен почти полностью, так как у него нет даже виртуальных методов (на самом деле, есть, но это врядли). Какой полиморфизм вы хотите от класса без виртуальных методов?

Проблема QImage и других подобных типов, что они реализуют implicit shared внутри, и не очень то располагают к дальнейшему наследованию. В случае Qt наследоваться приходится от скрытой приватной части, что мягко говоря неудобно.

А вообще можно использовать (написать самостоятельно) умный указатель, реализующий implicit shared технику, тогда корова останется коровой.

C++ (Qt)
implicit_shared_ptr< Cow > cow = implicit_shared_ptr< MyCow >::make();
 

Внутри implicit_shared_ptr скроется непосредственно share_ptr и метод detach(), реализующий клонирование MyCow.
Так как предполагается клонирование экземпляра произвольного типа MyCow, то хранить придется не сам тип, а обертку Holder поверх его (подобно boost::any).

Еще упростим (стоит статУя вообще без плюсов)

C++ (Qt)
struct SomeClass {
 ..
 BaseData * m_data;   // указатель на базовый класс
 ..
};
 

Типовая ситуация: SomeClass владеет BaseData и копии SomeClass имеют свои копии BaseData. Хотелось бы объявить m_data просто членом, но не выходит т.к. он полиморфный. Приходится объявлять указателем, тогда получаем серию мелких (пусть и не смертельных) забот - об этом указателе надо заботиться в конструкторе, деструкторе и при копировании. Также хотелось бы иметь корову на копировании. Вот собсно вся задача, что тут неясно

И вот я как-то не вижу как ее решить стандартными средствами. Все уперлись рогом в "уникальность", как будто других потребностей нет.

Да, тоже думал об этом, прошивать методы ref/deref как-то не тянет, да и хотелось бы класс-содержимое в это не посвящать. Если вумный указатель, то все проходит через операторы ->, *, ну может и сделать их константными, а для записи юзать get() или data() и там расшаривать. Потому что так

C++ (Qt)
template<class T>
struct cow_ptr {
 ...
 T * operator -> ( void );
 const T * operator -> ( void ) const;
 ...
};
 
cow_ptr<SomeData> ptr(new SomeData);
int a = ptr->mA;   // позовет неконстантный ->, сволочь такая