Если синтаксис языка будет заставлять использовать такой умный обработчик или заставлять разработчиков каждый раз писать LaTeX-like конструкции... Не завидую я разработчикам 😅

Быстрый поиск, копипаста и ссылки типа "использовать вот этот кусок но поменять тут и тут" по общей базе для всех проектов, наследование кусков "кода" из проекта в проект в режиме прототипа (если оно конечно технически реализуемо, особенно нечеткий поиск) - если посмотреть, пишем приблизительно одно и то же из проекта в проект, но не все языки умеют модули и наследование, приходится копипастить куски makefile, конфиги сборки, пересоздавать каждый раз файловую структуру, растаскивать декларацию и реализацию по разным файлам, итп

А что здесь такого страшного? В Fortress был отличный вариант отображения программы практически на уровне мат. нотации с типографским качеством. Так и область применения языка — выч. математика. https://labs.oracle.com/pls/apex/f?p=LABS:0::APPLICATION_PROCESS%3DGETDOC_INLINE:::DOC_ID:952

С точки зрения компиляторщика идея наличия множества внешних представлений у конкретного ЯП абсолютно естественна.

Как и одного алгоритма в синтаксисе нескольких императивных языков ;-)

доброй ночи

я так, почитаю...

Fortress не вызвал интереса даже у математиков, но Guy Steele продолжает питчить своё представление о математической нотации, теперь называя это Computer Science Metanotation. https://www.youtube.com/watch?v=dCuZkaaou0Q

Музыканты тоже разные бывают. Некоторые предпочитают линейный кодинг https://youtu.be/G1m0aX9Lpts

Есть линейка продуктов от компании Clickteam - они делают среды для разработки игр с упором на исключительно визуальное программирование с помощью условий и действий. Пилят аж с начала девяностых, я еще в школе кое-что в них делал. Порог вхождения действительно околонулевой, но зато возникает «потолок»: более сложную логику становится очень муторно описывать, результат перестает быть наглядным, ну и diff/merge стандартными средствами невозможен ибо файл проекта бинарный

Мб конечно дело привычки все.
Но я как-то дважды занимался визуальным программированием. Сначала на LabView, затем для генерации RTL-представления и загрузки на ПЛИСы. В обоих случаях очень простые задачи требовали значительного количества элементов. Там становилось столько всего много, что в голове не удержать. Даже если ты делаешь простой модуль и используешь его дальше.
Когда мы перешли на Верилог для дальнейшей работы с плисами - стало значительно легче. Потому что и компилятор(?) их брал часть работы на себя и просто конструкции стали лаконичнее. Стало намного легче писать что-то. Мы бы умерли делать MIPS-процессор(немного урезанный) визуальным образом. На верилоге было намного легче и это заняло не очень и много строк кода.  
Так что мб и правда пока что просто нет еще запроса на это. И нет идей как действительно делать таким же выразительными сложные вещи.
Возможно для легких вещей этот подход оправдан, но для сложных и объемных текст выглядит лучше.
Плюс как мне кажется чаще всего визуализируют что-то простое и короткое, а уже сложные и объемные вещи описывают текстом. Но это чисто мои догадки.

Вполне возможно, вы и правы :)
Просто закралась в голову странная мысль, что ввести оператор + с клавиатуры гораздо тривиальнее, нежели чем писать условное /operator_plus каждый раз

Не visual а visualizable, визуальное программирование в привычном виде просто не рассматриваю. В основе -  графовая бд, хранящая графы программ, исполняемые в среде (гомоиконичность). Пользовательский ввод короткие команды, и запуск граф-программ которые этот граф модифицируют, гуи ввод как опция. Части графа визиализируются пользователю как выборка запросами из графовой бд (запросы формулируются тоже в виде графа, или текстом).

Да, я уже прочитал после что было там выше.

Ну вот мб это имеет смысл конечно

Т.е. мышевозьню оставить по минимуму, только там где она удобна - набросать какой-нибудь конечный автомат, гуи форму, или несколько объектов соединить ссылками.

В общем, никто кроме нас. Была слабая надежда что хоть частично что-то готовое или похожее существует (хотя бы бд), придется пилить почти с нуля.

Есть https://luna-lang.org/ и он весьма неплох для прототипа. Они сейчас пилят версию 2, в которую и обещанные зав. типы хотят таки добавить в некоторый момент.

Графовых БД в последнее время предостаточно.

Ну или почти предостаточно - графового аналога SQLite я не нашёл.