1nd1g0, FTCG это проба пера, этакая попытка посмотреть, а как оно все должно быть устроено, если отказаться от классического подхода кодогенерации - по юниту на каждый элемент и карта связей между ними. Все прочие технологии, привязанные к стандартному пакету, это не более чем временное преодоление ограничений последнего.

RTCG изначально вынашивался не только как основной инструмент кодогенерации. Он так же должен стать единым средством для управления элементами как на этапе сборки проекта, так и на этапе его проектирования, т.е. фактически иметь возможность заменить конфиг (*.ini), исходник и часть функционала редактора свойств, который сейчас мертво встроен в среду.

Что касается написания элементов под пакеты на базе RTCG, то как уже некогда говорилось, большинство из них можно свести к однотипным шаблонам и обвязать мастерами, которые позволят разработчику создавать новые элементы на уровне Next->Next->Next->Next->Finish. В конце концов будет и инструмент, который по готовому классу (выполненному по определенным соглашениям) соберет такой элемент в полностью автоматическом режиме. Ну и очевидно, что исполняемый язык кодогенерации позволит сделать набор микроэлементов, способных собрать макро элемент (это уже на совсем отдаленное будущее).

Так же полагаю перейдем на несколько иную бизнес модель развития проекта: топовые пакеты платные ( .NET для Настольный систем, Android/iOS для мобильной платформы и некий X-WEB для сайтов) + персональные заказы на наробы элементов, среда 4.x FREE, среда 5.х GNU. И соответственно ориентируемся на западный рынок в первую очередь (т.е. базовый язык всех коммерческий решений - английский).