Коротко еще раз:
1) Смысл всей затеи очень точно был сформулирован в одной короткой фразе:

Дальнейшее развитие стандартного пакета именно к этому и приведет. Причины назывались уже не раз: достаточно часто не возможно из кода компонента убрать то, что не нужно пользователю в данный момент. Т.е. развитие пакета медленно, но верно ведет к его распуханию и снижению производительности на многие порядки. До тех пор, пока вы это не осознаете читать дальше не имеет смысла. Как и знакомится с содержимым этой темы тоже.

2) Имеется некоторая путанница из-за непонимания или незнания шагов потоковой кодогенерации. Точнее все привыкли к "кодогенерации" стандартного пакета, где её так назвать можно было очень условно. Скорее это не кодогенерация, а создание карты линков между элементами. Честная кодогенерация это создание кода приложения по шаблону. Язык, на котором пишется шаблон универсален и ни в коем разе не зависит от целевого языка. А вот целевым языком уже может быть PHP, JavaScript, HTML, Delphi или любой другой не важно какой. Пока разработчиком компонент такого пакета не будет до конца усвоено, что такое шаблон, то дальше в изучение можно даже не пытаться углубляться и не задавать вопросов типа "А как послать сообщение окну"...

3) Приведенные сслылки на справочные материалы содержат полное независимое описание скриптового языка. Приводить тут цитаты о PHP или JavaScript - это лишний раз демонстрировать непонимание работы потоковой кодогенерации. Galkov, упоменул о том, что 90% ядра языконезависимы. На самом деле это все 99%. 1% составляет разницу в операторе конкатенации строк целевого языка и символе обрамления этих строк.


должна стоять 163 версия с последним патчем. Так ли это?

[size=-2]------ Добавлено в 11:37
На счет поддержки: как правильно было замечено "кости даны, осталось облепить мясом". Следующий поддерживаемый пакет будет базироваться на основе языка С++. Причины так же не раз уже были сказаны.