Данный пост не спрашивает никаких решений. Считайте это рассуждения вслух - кто как.

Классика RAII:

По новому RAII:

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

Отказался от использования unique_ptr для таких (именно таких случаях, пусть это будет PImpl)
1.  Отсутсвует подсветка синтаксиса для m_data
2. Дебаг по коду позволяет ознакомиться с вырвиглазным кодом stl

Сразу отвечу противникам - даже если вы пропустили ваш делете, никто сейчас не программирует без профилировщика и не заметить пропуск такого явного удаления просто невозможно, причем в самом начале.

P.S. Пользуюсь ништяками c++11 давно.

Причем тут подсветка если ф-ционал разный.
Эти варианты неравноценны. QScopedPointer можно свободно копировать и отдавать по значению, а unique_ptr нет.

Вообще иметь unique_ptr членом как-то не очень, есть довольно стойкий рефлекс что оператор = и конструктор копирования принимают константные аргументы, а здесь это не так. Выносить моск ради жалкого delete - не вижу смысла

Простите, но вообще ничего не понял.

Программировать можно как угодно, лишь бы программа работала корректно).
А вот для ее дальнейшего сопровождения - это создает существенные трудности, даже если программа твоя.

В случае raw указателя ( Data * ) невозможно с ходу понять, что имеется в виду - значение, массив значений, полюс ассоциативной связи, композитная агрегация, совместная агрегация. Что?
Использование std::unique_ptr хоть как-то ограничивает этот перечень, не говоря уже о неявном new/delete.

Даже стандарт С++11/14/17 не доработан до такой степени, чтобы можно было четко отделять мух от котлет

class Test
{
public:
    Test(); 
    ~Test() = default
private:
    Attribute< Data > m_attribute; // данные, не участвующие в ассоциативных связях
    Unique<Data> m_unique; // полюс ассоциативной связи копозитной агрегации (участник ассоциативных связей)
    Shared<Data> m_shared; // полюс ассоциативной связи обобщенной агрегации (участник ассоциативных связей)
    Assocc<Data> m_assocc; // полюс ассоциативной связи, не являющейся агрегацией (участник ассоциативных связей)
}

А что это? Расскажите. Спасибо

Думаю ключевое слово "хоть как-то". Да, заявили что владеем, отвечаем за создание/удаление. Другие достижения? (не наблюдаю)

Это понятия ООП. Между объектами могут существовать отношения.
Одним из видов отношений являются ассоциации. Ассоциация означает, что экземпляры одного класса связаны с экземплярами другого класса.
Экземпляр ассоциации (связь) состоит из полюсов, связанных с объектами.
Часто ассоциативная связь реализуется в виде, когда её полюсы принадлежат одному и более объектам, участвующим в ассоциативной связи.

Частным случаем ассоциаций являются биполярные ассоциации.
Частным случаем биполярной ассоциации является ассоциация агрегации (отношение Часть/Целое). Целое определяет время жизни Части.
Со стороны Целого полюс ассоциативной может быть либо unique (уникальная или композитная агрегация), либо shared (обобщенная агрегация).
Со стороны Части может либо не быть полюса, либо быть none (полюс не агрегации).

Хотя в стандарт и ввели unique_ptr и shared_ptr, но кроме названий ничего общего полюсами уникальной (композитной) и обобщенной агрегации они не имеют.
При этом они могут быть использованы при реализации этих самых полюсов ассоциативных связей (наравне с raw указателем)) ).

На самом деле, не уверен, что отношения агрегации/композиции должны быть частью стандарта.
Вот например, композиция один ко-многим может быть реализована десятком способов:

Полюс - это значение, реализующее связь с объектом (ссылка, указатель, сам экземпляр объекта).

То есть, например, unique_ptr является полюсом, если его внутреннее значение задействовано в ассоциативных связях.
Тот же unique_ptr является просто атрибутом, если его внутреннее значение не задействовано в ассоциативных связях.