Пока что работа ведется над всплывающими подсказками. Мне кажется они должны давать некоторое разъяснение по строкам программы.

Ну что же пока проблемой является только Юникод. Остальное решаемо. Попробую исправить в следующей альфе.

http://narod.ru/disk/5819881000/Valenti … 5.rar.html - очередная альфа. Ввод/вывод реализован на уровне методов. В архиве имеется пример использования. Методы описаны в файле Поддерживаемые конструкции.rtf. Добавлено немного схем в документации (для улучшения восприятия). Один из файлов выполнен в FreeMind, прикольная программка . В прочем, если у Вас ее нет, там же имеется и просто в Jpege. Обновил Wiki от rusproga.
Реализация ввода/вывода на уровне встроенных методов (а не на уровне стандартных конструкций языка)  усложняет процесс переноса  реализации языка на Линукс и другие платформы, однако вручную по-прежнему осуществимо. Необходимо будет переписать код построения окон. Хотя перенос в Dos также возможен, в дальнейшем этот вопрос учитываться не будет.
Позже попробую использовать в работе Дракон (пока пытаюсь разобраться, что и как).

http://narod.ru/disk/6204660000/Valentina alfa7.rar.html - очередная версия затронула в основном среду разработки. Улучшения, удобства и прочее фокусы. Доступны горячие клавиши. Ctrl-M вызывает менюшку со встроенными методами. Слегка обновил Вики справку

С этого и надо было начинать.

К слову я искал строгое описание языка Паскаль (просто он мне ближе чем другие, и более понятен) в Интернете. Не нашел более или менее вразумительного варианта. Когда я уже считал что нашел что-то стоящее, посмотрел описание Begin-End и не нашел . В общем-то это не так просто как кажется на первый взгляд. Учитывая сколько лет концепциям Паскаля, то это несколько настораживает.

Некоторые обоснования использования русского языка в программировании (на основании печального опыта в Оберонкоре )

Основным недостатком использования русского языка в программировании считается тот факт, что русский язык не является международным стандартом в программировании. Следовательно, нет никаких гарантий, что Ваш код будет восприниматься программистами из других стран. Эта проблема действительно существует, но Валентина предназначена для обучения программированию, а не для создания интернациональных проектов. Кроме того, разработка Валентины ведется с учетом возможности использования в качестве языка для конструкций не только русский, но и родственные ему. Этот подход позволяет производить автоматический перевод программ в тот язык, для которого определен словарь конструкций языка Валентина. Кроме того, возможен дословный перевод в неродственные языки (аналогично Рапира, язык фирмы 1С и т.д. используют в качестве операторов руские слова дословно переведенные с английского. Так слово ДЛЯ никак не отражает своей взаимосвязи с циклами.). Такой перевод не отражает тонкостей реализаций алгортима, применительно к конкретной задаче и усложняет восприятие текста программы, но все же возможность существует. 
Кроме того, закладывается принцип "Машина для использования человеком" вместо "Человек для использования машиной". Эта проблема выражена следующим образом. Человек, использующий язык программирования с дословным переводом операторов, работает так: Думай-переводи-пиши. Человек, использующий язык программирования с записями конструкций в форме приближенной к естественной форме, работает так: Думай-пиши.
Разница в "переводи" порождает немало ошибок (часто программист предполагает, что конструкция работает несколько иначе из-за не точного перевода).
Вторым барьером считается использование составных конструкций (вместо КОНЕЦ использование ПРЕКРАТИМ РАСЧЕТЫ и т.д.). Но с чем это связано? Почему конструкции должны быть максимально короткими и состоять из минимального числа слов? Раньше это было связано с объективными причинами (экономия памяти машин), сейчас ресурсы позволяют использовать более сложные конструкции. Лень вводить длинные конструкции не является оправданием. Существуют языки программировния, управление в которых осуществляется одним-двумя символами. Примером является BrauFunck. Удобной для чтения программу, записанной на таком языке, ни как не назовешь. Если Вы хотите свободно читать (и понимать, что более важно), то что сами же написали год назад, имеет смысл использовать более подробную запись. Аналогично, если Вы предполагаете, что Ваш код будет доступен кому-то еще.
Задача - донести до программиста (а программы, как правило, не только пишутся, но и в основном читаются) реализацию данного алгоритма, а не предоставить программу. Это не одно и тоже. 
Аргументом в пользу использования длинных конструкций является спешка при наборе текста программы. Нет, быстрее программа от использования составных конструкций набираться не будет . Но число ошибок при наборе сократится (речь идет об ошибках логического характера, а не ошибки синтаксиса). Это отчасти и психологический подход - набрать и стереть программу несколько раз теперь будет немного дольше, чем скажем в С. Это должно заставить людей более тщательно думать над тем, что они хотят сделать непосредственно перед тем как приступить к реализации алгоритма на данном языке.

Не то, я не настолько силен в английском, чтобы свободно читать такие тексты. Я имел ввиду описание на русском языке.

Благодарю. По-крайней мере я пытаюсь получить что-то новое, а не просто неконструктивный флейм .

За одно можете поискать такую штуку как Coco/R (Компилятор Компиляторов). Идёт весь с исходниками и примерами. Есть версия и под Дельфи.
Поигравшись с ним Вы поймёте почему так важно составить формальное описание синтаксиса языка. Coco/R позволяет по формальному описанию синтаксиса генерировать практически готовый компилятор, а именно сканер и парсер. Для получения полного компилятора нужен ещё генератор кода. Вам он по-идее даже не нужен, так как у Вас интерпретатор.