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