Так вы определитесь, нужно копирование или нет?
Этот указатель владеет ресурсом, на который указывает. Вы копируете объект с таких указателем, кто после этого должен владеть этим ресурсом: исходный объект или его копия?

мувать

Собственно возможности всего две - размещать экземпляр объекта в по месту владельца, либо отдельно в куче.
По разным мотивам может потребоваться любой из этих вариантов.

Мувать нужно и в том и в другом случае, собственно, как и копировать. В случае с указателем выше move дешевле, копирование дороже).
Всяких указателей можно наделать сколько угодно много, обеспечить, например, с помощью них потокобезопасность (https://habr.com/post/328348/).
Главное - сформулировать ожидаемое поведение и вперед...)


Стандартные указатели декларируют конкретное поведение, которое покрывает далеко не весь спектр возможных задач.
Имхо, именование их shared и unique еще и могут ввести в заблуждение, что это понятия объектно-ориентированной модели).

Поведение, которое необходимо в задаче, не обеспечивается с помощью стандартных средств.
Прежде всего, по причине, что это указатели, и ожидается что они ведут себя как указатели, а не экземпляр объекта, на который они указывают.
Поэтому использование дополнительного класса здесь вполне оправдано, и не является "велосипедом" по отношению к стандартным, так как реализует совершенно другое поведение.

Вы так и не ответили на вопрос Old'а: нужно копирование или нет? Опять все догадываться должны, что Вы там себе придумали? Чтобы покласть объекты в контейнер, не обязательно их копировать, можно перемещать.

Допустим таки надо копировать.

1. Если совсем лень, можно попробовать использовать std::optional. Но затея не из лучших.
2. Написать метод, который копирует объект по указателю в том смысле, в каком это нужно для заданного класса. Навскидку:

C++ (Qt)
std::unique_ptr<SomeClass> makeCopy(const std::unique_ptr<SomeClass>& from);

Соответственно придётся написать конструкторы/операторы копирования. И лучше использовать std::unique_ptr, чем QScopedPointer.
3. Написать обертку с нужным поведением, как предлагает ssoft.

Ну хоть спрашивать начинают, и то хорошо. А то обычный подход: "Не получается с unique_ptr? Меняем на shared_ptr и ... в продакшн." .

Вот именно, "наделать" можно, но дальше велика это никуда не пойдет. С интересом прочитал статью, оказывается можно как-то хитро привязаться к оператору ->, не знал. Да, познавательно, но.. на этом все и кончается - практически никто и никогда таких огородов городить не будет. Слишком сложно по сравнению с достигаемым рез-том. Ну и вообще
Если контейнеры позволяют такую конструкцию, то они по своей природе не могут быть "потокобезопасны", т.к. время жизни ссылки неизвестно и др нитки прорваться не смогут. Можно создать какой-то ограниченный вариант, это интересно, хотя и жить не будет. C'est la vie

Вы сказали много интересного и нового, но то что интересно - не ново, а то что ново - не интересно"

Мне известно что нормального стандартного решения здесь нет, и обвинять QScopedPointer нет оснований. В конце-концов член "просто указатель" (от которого сейчас модно воротить нос) тоже потребует перекрытия копирования/присваивания - но никаких ошибок не выдаст и загнется в runtime, в этом плане QScopedPointer если и не лучше, то корректнее.

Часто заводят флажок с именем типа "shouldDelete" А отдавать - да. "голый", лучшего не видно

Что касается "сущностей" и.т.п. Ну вот есть "просто член класса", агрегатом, не указатель  - он почему-то прекрасно копируется. Интуитивно QScopedPointer - такой же член, который однако может быть и null. И что с того - почему он не копируется? Чему это противоречит? Оригинал владеет своим экземпляром, копия - своим, "уникальность" соблюдена. Как-то нынешнее поведение неестественно  

А пожалуйста.