Насчет формата файла проекта.
Так-как речь не идёт о хранении внутри проекта больших объёмов мультимедийной информации формат XML будет предпочтительнее чем бинарный файл. И вот основные достоинства:
1. Полно стандартных парсеров.
2. Легко разобраться со структурой.
3. Легко отлаживать (просто видно глазами что не так).
4. Легко реализовать свой механизм сереализации в XML.
5. Полная поддержка UTF-8.
6. Сторонние разработчики легко смогут присоединиться к пректу и добавлять в файл проета свои вложения с данными плагинов.
7! Не нужно дополнительно заботиться об обратной совместимости пректов, сохранённых в разных версиях программы.
8. В XML можно добавлять бинарные данные.
Простейший механизм сериализации:
1. Каждый класс должен уметь сохранять и загружать себя из узла XML. Для этого у него должна быть пара методов: SaveToXML и LoadFromXML. Первый метод-функция возвращает XML-узел с сериализованным экземпляром класса. Второй процедура -- получает через параметр узел и пытается из него загрузиь своё состояние. При ошибке должен генерироваться excepton определённого класса с указанием причины ошибки.
2. Активно используем наследование, инкапсуляцию и полиморфизм. Создаём абстрактных предков с виртуальными методами описанными выше. Потомки этих классов должны лишь перекрыть виртуальные методы и добавить в узел свои поля и вложенные узлы.
3. Каждый класс должен знать свой тег. В качестве тега можно использовать название класса, а классы зарегистрировать в едином списке, дабы по имени можно было получить класс (это, кстати, можно поручить RTTI). Таким образом каждый класс сможет определить может ли он грузиться из данного ему узла или следует сгенерировать exception.
4. Используем коллекции. Делаем предка всех сохраняемых коллекций и учим его сохранять в XML-узел своё содержимое.
5. Делаем предка всех элементов коллекций и учим его сохраняться в XML. (Всё! Любые коллекции сохраняются одной строчкой!)
Как это применить в конкретном случае.
Берём простенький и шустренький парсер XML. Например этот:
Объектная модель этого парсера построена на основе интерфейсов. Работать с ним просто. Не надо заботиться об освобождении памяти и уничтожении объектов. В прилагаемом примере и справке всё просто и наглядно показано.
Так же в XML можно хранить и настройки программы опираясь на ту же самую модель сериализации. Можно хранить пресеты с настройками, а так же настройки плагинов, которые когда-то таки появятся, если проект не зачахнет.
Аналогичной расширяемости с использованием бинарных файлов можно добиться только реализовав чунковую структуру, аналогичную формату файлов, например 3dMAX. Однако о читабельности, прозрачности и простом стандартном парсере придётся забыть.
Если бы мне удалось посмотреть последнюю версию Ваших исходников, возможно я ещё каким-нибудь советом мог бы облегчить вам жизнь=).
Ну и вопросы.. Задавайте, если что не понятно.
Насчет того, что ещё нужно добавить в данные о проекте:
1. Глобальный уникальный идентификатор проекта.
2. Глобальный уникальный иднтификатор версии.
В качестве них можно использовать обычные GUIDы, которые используются в технологии COM. Для их генерации помимо WIN API есть, также, и независимые от платформы функции.
Нужны эти идентификаторы, чтобы однозначно определять и различать разные версии одного и того же проекта. Ведь в перспективе речь идёт о каком-то интернет-хранилище?
В любом случае
используя XML структуру нам не придётся дополнительно заботиться об обратной совместимости проектов. Это очень важный плюс, который я, кстати, чуть не забыл упомянуть выше.
Прст по моему мнению, проект не дорос ещё до стадии чего-то приличного. Но если вы настаиваете...
. Хотя, врядли. 
