Мне может кажется, но Netspirit говорит примерно то, что мне пришло в голову, пока я читал последние две страницы.
  Во-первых, идея сделать свой "графический язык" - правильная, однако тут совсем не то, что имеет в виду nesco: надо не определять, как будет и что рисоваться - это лишь метод представления программы на графическом языке пользователю и рисоваться она может как угодно (конечно, лучше прийти к единому удобному и функциональному решению, но модульность - тоже хорошо, можно будет делать свои попытки представить графический язык). Во-вторых, основа языка, так сказать, его семантика должна быть в компонентах.
  Определим, что же важно программисту на графическом языке? Правильно - реализовать логику, его не интересует ни целевой язык, ни особенности компиляции, - только результирующая логика работы. Из этого приходим к следующему: на уровне графического языка не должно быть не деления на пакеты. Пакеты в том виде, в каком они сейчас, должны быть простым ComboBox-ом, в котором просто выбираем целевой язык (так мы получаем кроссплатформенность и различные языки одним ударом). Далее, компоненты должны быть едины для всех пакетов, мы составляем схему из логики, а не из наборов компонентов для целевого языка.
  К сожалению, это очень идеализированное представление графического языка, и оно имеет свои крупные изъяны:

• Так как набор компонентов один, то при поддержке множества целевых языков придется реализовывать одну и ту же логику для каждого языка. Это ооочень трудно и затратно по времени (а в некоторых языках такую логику и вовсе придется реализовывать целиком самому, а не использовать библиотечные вызовы).
• Очевидные кончились (или забылись, пока дописал до этого места). TODO: заполнить.