Не, там подразумевается по-другому маленько - многоэтажный кросс обходится по принципу "направо и вниз до "земли", а после неё - на нужный уровень". Т.е. можно считать, что промежуточные горизонтали-поперечины однонаправлены (по стрелкам замыкания этажей). Собственно, это пояснялось на примере:download/file.php?id=2426&t=1.
Возможен другой синтаксис - с раздельными поперечинами. Тогда верхняя в паре для выходов одного уровня, нижняя - для входов нижележащего. Что даёт ту самую естественность. Так сделано в другом примере:http://grafit-basis.narod.ru/images/Pag ... n_curr.png.
В обоих вариантах минимизируется требуемое число линий кросса - для удобства и изображения, и чтения (навык обхода формируется автоматически, как и в языке ЕСКД-сетей - но эти варианты несколько упрощены даже по сравнению с ним, ибо графит-метод предназначен и для "нетехнарей"). В общем синтаксис разбирался вэтом подпункте.
Ессно, разработчик может принять свои решения - в то же время интересны их мотивы...

7) Хорошее дело. А будет реализовано как включатель языков схемы (для Вашего предложения - указанием префиксов ДОК и КОД)?
И ещё - как уже писал в этом посте, элементы описания разной формальности могут находиться в разных отношениях. Скажем, один комментарий (или даже его часть) м.б. отнесён к двум и более операторам или фрагментам кода (повторно входить в описание). Так вэтой задаче- у процедур прошивки есть общие части комментариев (повторное использование которых оформлено через ссылки на частные записи). А также к одному фрагменту кода могут относиться два и более разных комментариев. Так у Вирта в "Проекте Оберон" - что Вы могли видеть в описании процедуры Edit для текстов - на некоторые диапазоны номеров элементов кода написаны разные комментарии. Как бы эти отношения представить в синтаксисе модели? и показывать такую структуру?..

Кстати, то же справедливо для отношений с элементами третьей непренебрежимой (при гарантоспособности за счёт формализации) категории содержания - математической (утверждений об операторах и конструкциях). Но структуру отношений в тройках элементов выстраивать сложнее - а в Ваших условиях РДП эта составляющая не обязательная.
В принципе реализовать бы попарные связи - а математику можно и в ДОК-часть включать. Но, т.к. у Вас запись гладкотекстовая - то хорошо бы реализовать из комментариев гиперссылки на закладки во внешних документах (открытого формата). Там м.б. не только формулы - но и полноформатный текст и изображения - всё. что нужно для спецификации конкретной задачи.

6) Синтаксис внутри среды подразумевает ведение двух описаний автономной единицы ДАЛВЯЗ-модели (кстати, то, что Вы её называете "модуль" - это связано с одноимённым понятием реализуемых ЯП)? Или д.б. какое-то единое описание с "мультилингвами" для отдельных элементов?
И ещё - в принципе ведь охранять выбор ветви в ЦС (как эмуляции ЦД по КомПас-типу) можно не только сравнением номера - но любым логвыражением (и не обязательно от чисел-скаляров). Как пример здесь:download/file.php?id=3255&mode=view- ветви дейкстрала выбираем по элементам множества, трактуемым сами по себе как булевы переменные. Очевидно, автоматически подставить как охрану ветви произвольную переменную (из числа употребляемых в "подвальных" присваиваниях) тоже можно? А в перспективе - реализовать форму конструирования охран из величин программы?

5) Сответственно нормализация именно номеров веток будет не так актуальна.

4) А что, если реализовать полноценное двумерное структурирование кода на базе ЛСП? И тогда не делать отдельно "полуторамерный" текст с простыми интендациями - а отображать всегда единый текст как "схему со снятой графикой" - или в другом понимании, как ЛСП с расшифровкой операторов и строгим упорядочением вертикалей в смысле Ермакова-Жигуненко? Можно опционально показывать там и Ваши псевдографические разграфки ЛСП-столбцов... а также включать свёртку линейных участков (до каких-то номеров, как у Вас, или как-то иначе)...

3) Ну, из сказанного выше, видимо, понятно, что код и комментарии к нему в общем случае есть часть инструкции... Но, если мы для этой части, кроме измерения "неформальный ДОК/формальный КОД", также введём независимо-детализирующее языковое (для дока - то же РУС/АНГЛ/.., для кода - по реализованным инфор-языкам) - то это будет важный шаг на пути Разработки и Документирования...
Тут важно - чтобы инфор-языки были в единой парадигме - когда просто синтаксис операторов и конструкций разный, а за ними стоит одинаковый смысл. Иначе придётся вводить ещё уровень детализации по парадигмам...впрочем, у Вас все языки трактуются как процедурные, а типы и связанная с ними возможность объектности/функциональности не раскрываются в среде...

2) По этому тексту см. сказанное для 4).
Понятно, что следует решать вопрос с отображением текста достаточно произвольной ширины. Тут многое будет зависеть от того, будет ли выбран текстовый или графический режим вывода. Видимо, надо всё-таки остановиться на графическом.

1) Хотелось бы, чтобы слова для человека писались бы всегда полностью. Кстати, и для транслятора с ТЯП ведь это требуется... так зачем же ещё вариант написания того же самого?.. только реализацию усложняет...
Впрочем, можно предположить мотив - чтобы ЛСП в текущем варианте м.б. жёстко форматировать с постоянной шириной столбца. Однако в связи с 4) это должно стать неактуальным.

Ну и в целом - как-то стремиться к тому, чтобы и новая ЛСП, и схема были бы просто вьюшками от файла описания. Оперативно связанными с текущим состоянием редактирования...

А в общем мысли по-прежнему интересны. Удачи!