Не смотря на вердикт. я изложу свое видение:

• что делать со связями, при распахивании больших схемКак я и раньше предлагал: увеличить общую схему ровно на ширину и высоту схемы контейнера.
  Связи пришедшие в сжатый контейнер слева и сверху, как были вверху так и останутся.
  Верхний левый угол контейнера останется в той же точке сетки, что и был. Верхний правый - переместится вместе со всей схемой вправо на ширину схемы. На контейнером не будет ничего. Все связи будут приходить в него или слева или справа, но до правой границы.
  
  Сжатые вместе ладони: развели ладони (только правую) - увидели схему. Все что было до правой ладони - плавно уехало вправо.
  Та же песня с хомячком и черепахой и с низом - по аналогии. Верхний угол - закреплен.
  Здесь есть ньюанас, но при желании и его можно убрать. Ньюанс в том, что не ясным остается вопрос, что делать, если между левым и правым, к примеру, углом свернутого контейнера если там были элементы. Решение - считать началом шторки не размеры свернутого контейнера - а его левую, и соответственно верхнюю часть.
  
• почему нажать на кнопку "Распахнуть" это быстрее чем нажатие на кнопку "Войти внуть контейнера"Не быстрее, Dilma, путаете. Удобнее. Удобство в том, что распахнув контейнер я увижу схему и связи между элементами внутри контейнера.
  А войти внутрь означает что я должен запомнить что было снаружи, войти внутрь и понять, что вот эти связи идут к тем или иным элементам наружу. Вот это неудобно, то.
  Я уже приводил аналогию с матрешкой. Приведу и сейчас - при реализации регионов - я могу посмотреть связь с самой маленькой матрешкой. Сейчас - нет. Я должен войти в среднюю,, потом в маленькую и потом по памяти (!) восстановить связи и понять, что тут вот не так.
  
  Но и это еще не беда: одно дело понять куда идет, а совершенно другое дело - ее провести. На каждом из контейнеров я должен создать точки, и находясь сначала в одном провести связи, а потом войти в другой, и т.д. Как минимум по 2 связи (вход и выход).
  
  Я даже написал на баг-трекере пожелание (№168) и Вы его приняли, поняли в этом меня. Это предложение возникла как раз именно отттого, что порой очень сложно определеить при множественной вложенности - куда ведет связь. Но повторюсь еще - одно дело определить куда ведет - другое провести.
  
  
• почему перекрытие всех близстоящих элементов распахнутым контейнером более наглядно, чем окрытие кнутренней схемы в отдельном редакторе.На видео мной демонстрировалось не это. Я сожалею что меня так поняли в очередной раз. Была демонстрация вот чего: есть контейнер развернутый - и в него идут связи. Контейнер свернули - связи как шли в него, так и идут. Развернули- поработали, протянули новые - все, ничего не мешается более.
  

oldTV, что то как то все сложно.... даже не знаю как все прокоментировать это.
но на данный момент есть удобная фича.... это хинт мультика. т.е показывает внутренности мультика в виде подсказки (Ctrl + курсор на мультик)

Про протягивание сквозь схем... тоже незнаю... ведь каждый мультик это уже отлаженный кусок... что там еще протягивать...

Может все предложенное тобой и было бы удобно, но ведь связи скакать будут "туды сюды" а это не есть красиво... каждый раз перерисовка связей.

При реализации моего представления - связи скакать не будут. Будут удлиняться линии. Ровно на размеры контейнеров.

На видео редактор не дает представления об этом, зато дает представление о вложенности. Скачайте и запустите, перейдите в ноды и поэкспериментируйте. Увидите что удобство есть.
Подумал тут о другом: я не описал алгоритм как быть, если к примеру связи пришла строго сверху.
Когда справа или слева - понятно - просто удлинение. Когда сверху - вначале сдвиг на размер сжатого контейнера вправо, затем алгоритм описанный выже.
Тоже и по верху, только сдвиг вниз.
Еще сложность - за которую Вы сейчас все уцепитесь и будете ей меня тыкать - как быть с тем, если при раскрытом контейнере элемент помещается не внутрь, а в пустое освободившееся для раскрытия контейнера поле. Вот тут я пока в ауте. Буду думать.

Все равно вердикт есть уже. Думай, не думай, тема закрыта к реализации.

Это, пожалуй, главная идея инкапсуляции в ООП. Правильно построенный (и задокументированный) интерфейс организационной единицы, в данном случае "мультика", единственное, что мне нужно. И в дальнейшем при разработке схемы, детали реализации мультиэлемента мне уже неинтересны. Постоянное "ныряние" внутрь - признак непроработанной реализации, а создание и переопределение внешних точек - признак непродуманной интерфейсной части. В этом случае мультиэлемент удобнее представить в виде некого "черного ящика", содержимое которого недоступно - доступен только требуемый функционал через ранее определенные интерфейсы "мультика".

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

Я, продумал алгоритм реализации..
Пока домой ехал.
Сейчас приеду - изложу. Но пока я 2 последние сообщения не понял. Кто в итоге за, кто против?

Несмотря на вердикт предлагаю дискутировать активнее, серьезная ведь тема
------------ Дoбавленo в 22.48:
Почти окончательный вариант по реализации:
1. У мультика 2 состояния - свернутый, развернутый. Ширина развернутого = ширине схемы, внутри мультика + 20. Высота = высота схемы + 20. Ширина и высота свернутого зависит от количества точек.
2. При разворачивании верхний левый угол закреплен и все элементы схемы находящиеся справа от вертикальной линии проходящей по левой стороне свернутого мультика сдвигаются вправо на Ширину свернутого мультика + Ширина развернутого. Тоже по высоте, но только вниз.
3. Связи при этом не изменяются, а остаются на том же месте, только линии до точек будут удлиняться на ширину схемы+ширину мультика или по высоте на высоту схемы + высоту мультика. Происходит при разворачивании как бы эффект раскрытия или сдвига.
4. Проблема позиционирования элементов после раскрытия решается так: каждый мультиэлемент - это слой схемы. Все мультиэлементы распределяются как слои и переходы между ними, словно переходы между слоями. Чтобы положить элемент именно на мультик - элемент должен быть помещен в рамки развернутого мультика. Иначе он попадет на тот слой (читай мультик или самый верхний уровень) который будет выше уровнем. Равные мультики (!) - вне зависимости от состояния (свернуто или развернуто) - будут видны на одном слое, который будет иметь более светлый фон. Другие слови при этом - затемнены (чуть чуть). Перекладывать элементы со слоя на слой можно перетаскиванием и удерживанием в течении некоего времени. Такое же удерживание позволяет открыть мультик на одном слое.
5. Точки, как я и говорил ранее, должны образовываться по факту того, что связь идет от одного элемента внутри мультика, куда то вне его.

Резюмирую: развертывание идет слева сверху вправо вниз. Все элементы сдвигаются в ту же сторону. Каждый мультик - располагается на слое или уровне. При развертывании какого либо уровня - доступен к активному просмотру только этот слой и слегка затемнен верхний и все нижние. Перемещение описал выше.

Как то так...

Ругайте, вердикт все равно уже вынесен...

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

Ivann, как размер схемы связана с размером экрана? Никак по моему... Скролл - это размер экрана.

oldTV, скрол, это когда схема, большая схема выходит за границы области её отображения, необязательно экрана.

а чего тогда? в моем представлении о скролле - только экрана.
внутри мультика конечно может быть, но зачем? В чем тогда цимус?