Непонятна проблема. Закрывайте всё в НАЧАЛЕ деструктора главного окна.
Всё у вас будет, гуи висят, данные стоят, синглтоны спокойны.

PS или распишите проблему подробнее, а то непонятно

Удалит все объекты, которые на них ссылаются.
Это же прописные истины, разве нет?

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

PS тем более дальнейшая судьба шаред поинтеров нас не интересует. Нас интересует финализация - сохранение результатов перед закрытием программы.

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

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

Попытаюсь объяснить на пальцах ).
Вобщем есть объект, который отвечает за хранение неких логических объектов. По сути хеш таблица с кучей методов досутпа к элементам этой таблицы.
Есть объект, которых хранит указатели на элементы на сценах (сцен может быть несколько).
Есть объект, который хранит связи между логическими объектами и элементами на сцене.
Есть объект, который хранит контроллеры-обработчики, сущности отвечающие за отрисовку элементов на сцене в зависимости от состояний логчиеских объектов.
Еще куча глобальнных объектов, которые отвчеают за воспроизведение звуков, конфигурацию программы, и еще туева хуча таких объектов.
Часть глобальных объектов описана в одной либе, к которой линкуется экзешник. Часть таких объектов подгружается в плагинах.
Суть в том, что в любом месте проекта (т.е. как в исполняемом файле, так в любой либе, в любом классе проекта) нужно иметь удобный доступ к этим объектам.
В самом начале я хранил указатели на них в каждом классе, но это утомительно сопровождать, так как по сути:
-эти объекты (как я их назвал для себя менеджеры) существуют в единственном экземпляре
-они глобльны для каждого экземпляра программы
-могут добавляться новые.
Потом решил использовать шаблон Mediator. Хранил в хеш-таблице указатели на эти объекты по некоторым строковым константам. Но так же столкнулся с множеством неудобств, таких как
-нужно было хранить копии указателей на эти объекты, получать их и кастить
-баналаная опечатка могла не дать найти этот объект по ключу (позже решил это через public static const QString константу каждого класса менеджера)
-и еще куча мелких заморочек которые мешали спокойно жить.
Вот и пришел к выводу, что эти менеджеры по сути есть синглтоны.
Теперь по поводу их создания и удаления. Почему то в голову пришла идея, что каждый синглтон должен инициализироваться в своей библиотеке. Потому что есть подгружаемые плагины, и не хотелось бы явно указывать в конструкторе главного окна создания всех этих менеджеров. Но проблема в том, что порядок удаления обратный, и когда главное окно уже разрушено, вызываются
деструкторы менеджеров в своих либах. И конечно же вылетает сегментация, т.к. доступа к некоторым объектам уже нет (гуи и не только).
Так же есть менеджеры, которые зависят от других. Почти в каждом менеджере используется менеджер логических объектов, потому что вокруг них все и вращается по сути.
Сейчас пришла в голову мысля чтобы сделать один синглтон, который будет отвечать за создание и удаление менеджеров, он будет вызываться в конструкторе и деструкторе главного окна, и будет хранить фабрики остальных менеджеров. Фабрики будут создавать и инициализироваь нужные менеджеры а так же их финализировать и удалять. Посмотрю на сколько это будет удачное решение...

Какое-то чуждое словечко "финализировать" (явно с жабьим уклоном) Давать советы здесь сложно, но вот что бросается в глаза

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

Это нормально, по существу так же работает и шаред пойнтер (хотя он и не обязан быть синглтоном). НО это предполагает что сами мы (руками, delete) ничего не удаляем. Так нельзя, вся система теряет смысл, придется очень мучительно отслеживать всех кто может еще пользовать удаляемые данные - явный говнокод.

Очень сомнительно чтобы менеджеры удалялись ДО главного окна, как Вы хотите. Когда начинает выполняться код деструктора, объект еще полностью валиден - и значит может потребовать нужный синглтон. Предполагать что "такого у меня не будет" недальновидно. Первое что приходит в голову - не удалять, а деактивировать синглтоны. Хоть завести флажок "inDestruct" по которому все обращения синглтонов к эл-там UI блокируются. Qt делает подобным образом для qApp. Да, это немало проверок (и/или ассертов) в коде всех синглтонов - но лучшего может просто не оказаться.

По поводу нового увлечения фабриками - в данном случае неясно что Вы хотите от них получить. Как только Вы откажетесь от подхода в стиле шаред пойнтера - Вам придется отслеживать все связки руками (ну его нафиг).

Используйте QSharedPointer только у владельца объекта, а в остальных случаях для хранения указателя используйте QWeakPointer.

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

На мой взгляд у вас проблема в архитектуре, а не в каких то мифических "удаляется раньше позже".

Последуйте совету Igors и выберите архитектуру, сделайте наброски алгоритмов, и только после того как сами всё поймёте, начинайте кодить.

PS Если не видеть полную картинку, а программировать частями, получится фигня. Хоть какой то план надо иметь.