Кажется, проблема всех систем тайм-менеджмента в отсутствующем целеполагании. Упоминавшийся Любищев имел большую цель в жизни. Настолько большую, что в одну жизнь она не вмещалась, и он был просто вынужден свою жизнь перетряхнуть и утрамбовать, чтобы она стала более пригодна для его стремлений.
Чудесно быть таким человеком, который в силах оцарапать земную кору, но сколько таких людей? Может 5%? А может 1%?
А вот что делать людям не выдающихся, но нормальных средних способностей? Такие люди все же могли бы достичь больших успехов: создать стартап, стать известным блогером, выучить иностранный язык и уехать в другую страну (подставьте любой другой результат, требующий вложения времени). Правда, ежедневный просмотр котиков почему-то побеждает эти стремления. Эта проблема очень интересная, по моим личным наблюдениям распространенная, и она совсем не про тайм-менеджмент.

Неполная автоматизация профессий гораздо гуманистичнее и гм… безопаснее для общества. Полная автоматизация — это сотни тысяч (миллионы?) работников, в один момент ставших ненужными. А вот 30% или даже 80% освободившегося времени кто-то заполнит фейсбуком, кто-то наркотиком, а кто-то (как еще в одном фильме):
— С тоски попробовал читать, — оказалось увлекательное занятие.

Предметная область как раз определена хорошо. Это личная продуктивность и тайм-менеджмент. На эту тему написано много томов, но существенно различных стратегий управления делами может быть не так много. Если стратегий мало, то и интересных комбинаций много не получится. А значит, открытая платформа-конструктор не будет иметь преимущества перед каким-то специализированным планировщиком. На мой взгляд это ключевой вопрос, который нужно проанализировать, чтобы понять, есть ли потенциал у вашего конструктора.
А интеграционных модулей можно придумать бесконечное количество. Экспорт-импорт данных, синхронизация, всякие гаджеты, оформление UI. Это все полезно, но не то, что создает продукт.

А вы пробовали анализировать предметную область? Сколько, действительно, различающихся по назначению модулей там можно придумать? То, что приведено у вас в разделе «Перспективы», — это (помимо машинного обучения) интеграция со сторонними устройствами.

Просто глобальные переменные с неопределенным порядком инициализации, разумеется, хуже любого организованного подхода. Но у организованного подхода тоже есть свои проблемы. Например, у вашего — это код, выполняющий g_storage.AddGlobalObject<> / g_storage.RemoveGlobalObject<>.
В нем легко допустить ошибку, особенно учитывая, что что для каждого набора Mock-объектов необходимо создать и поддерживать отдельную функцию, заполняющую g_storage.

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

В общем, ваш подход хорош для глобальных объектов, которые сами никого не используют, а все используют их. Например, для таблиц свойств, генератора случайных чисел и прочего. Mock-объекты создавать с таким подходом, действительно, удобно.

1. Кто отвечает за инициализацию глобальных объектов? В вашем примере, насколько, я понимаю, этим занимается функция Test().
2. У вас не рассматривается случай взаимозависимости глобальных объектов и возникающие при этом проблемы с созданием и, особенно, удалением глобальных объектов.

Остроумно придуман критерий бесплатности.

Пользовался лицензионной версией для корпоративного проекта (большая кодобаза, > 15 лет разработки).
Несколько мелких, но вредных ошибок PVS нам поймал.
Теперь обязательно буду применять этот инструмент и в личных проектах.