Igors, BRE! Это не относится к данной теме!
Igors, если желаешь обсудить эти вопросы, создавай отдельную тему. Не надо мешать все в одну кучу.

Да с какой стати они отсюда вытекают? Совершенно не связанные задачи!
Есть система объектов, сохраняем в поток, восстанавливаем из потока(как было или как хотим).
И всякие операции удаления, перемещения объектов в рамках системы(до ее сохранения или после чтения) никак с этим не связаны!
Записал систему в файл как есть. Делай с тем что в памяти что хочешь.
Создал  систему (прочитал из файла). Делай с тем что в памяти что хочешь.

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

А если этот объект parent для других объектов и они рассчитывают на валидный parent? Ступив на "скользкий путь", мы должны по нему идти и идти. Почему мы создаем флаг "не валид"? Из идейных соображений? Вовсе нет, давайте признаемся - надо закрыть очередную дыру

Spectre, согласен, но уже начали обсуждать здесь. Может модераторы смогут разделить.[/quote]
Не могу с Вами согласиться. Если мы сказали - связки должны работать "по указателю", то мы себе и создали букет проблем которые потом будем решать и решать.

Использование "просто указателя" для серъезных данных (вне UI) плохо!

О боже, как кощунственно это звучит 

1) Связь объектов между собой и динамика их отношений:
  - parent <-> children
  - object <-> ref
  - owner <-> children
Это твоя проблема которая зависит от условий твоей задачи и твоих ресурсов итд..., о которой здесь никто пока не знает.

2) Абстарктные высказывания типа "давайте признаемся - надо закрыть очередную дыру" или "то мы себе и создали букет проблем которые потом будем решать и решать", это от бессилия, лени или злости, и никакого отношения к делу не имеют. Так что давай последовательно и конкретно.

3) А это вообще откуда вылезло.

1) У меня куча разных объектов и разных базовых списков с ними, а также ссылок и списков со ссылками на эти объекты. И никаких проблем с невалидностью ссылок на объект после удаления его где-то(например в базовом списке) не возникает. Я просто не допускаю таких ситуаций! Удалил объект - удалил(или обнулил) ссылки на него, а как правило лучше наоборот сначала разбираемся со ссылками, а затем уже удаляем объект.
2) Не спорю, что в некоторых случаях это не удобно, но как правило такие случае возникают из-за плохого проектирования. В исключительных случаях можно пользоваться всякими "умными указателями" и им подобным вещам. Нужно ли это и какая модель того-же "умного указателя" или какого-нибудь "мультиссылочного супер-саморастворяемого объекта" необходима зависит от твоей задачи.

Я своего мнения не навязываю. Если у Вас в проекте таких злосчастных проблем нет - то и слава богу. Просто у меня они есть и уже достали конкретно  
Я и не претендую чтобы "чудесная система/механизм" за меня undo делал. А хочу просто писать undo разумно.  

Для меня всякое копирование исключено. Объекты должны быть реально удалены и указатели на них будут невалидны. Снимать копии системы мне тоже не подходит (боюсь диска не хватит). Давайте на том же простом примере:

Есть 3 объекта QString. Пользователь удалил 2-ю. Естественно, перед удалением мы записали ее в стек undo. Все хорошо, но эта строка входила в set(ы). Значит и указатели на нее в set'ах должны быть удалены. Как сказать undo что надо восстановить связки?

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

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

1) Базовый объект(аналогично QObject) назовем IObject в отличии от QObject может привязываться ко многим родителям, соответственно имеет как список детей, так и список родителей.
2) Аналогично QObject, при удалении IObject, в деструкторе, удаляет себя из списка всех родителей вызовом метода "removeFromAllParents", это метод публичный и может быть вызван без деструкции объекта(отвязка от родителей)
3) Родитель, в зависимости от его типа, может так-же вызвать removeFromAllParents ребенка и после уничтожить его, или просто вызвать метод ребенка removeFromParent(this)
4) Можно для IObject иметь только одного Главного родителя(котрый разрушает) и список Дополнительных родителей(которые просто связаны) с ним.

Дальше развивать не буду. Подобные схемы взаимодействия объектов решают твою проблему удаления из sets при удалении из главного set. Или другую задачу, разрушение объекта при удалении из всех sets(или последнего который его содержал). Еще решаются проблемы аналогичные оповещению всех(или части) родителей об изменении состояния объекта

====
Теперь по поводу примера.
Сделай классы IMainSet, и ISet. С Каждым добавляемым IObject связан флаг актуальности (int), если он 0, то IObject актуален(содержится в set), если нет, то IObject отброшен. флаг типа int для отслеживания уровней отброшенности.
IMainSet имеет метод destroyObjects(int level=0), разрушает все IObject с флагом >= level. Метод removeObject не удаляет объект, а меняет его флаг актуальности.
IMainSet - для главного предка, ISet - второстепенных.
Используя систему оповещения IObject всех своих родителей об изменении, легко автоматически сменить актуальность объекта во всех sets одновременно.
Это просто набросок, захочешь сделаешь как надо.
Дальше развивать не буду, устал.