Возьми наудачу трех фортеров и у одного этот уровень будет ближе к начальному, у другого, наоборот, завышен, и только у третьего - средним (между ними), если, конечно, он не уйдет слишком далеко в сторону.

Да. и это весьма плохо, потому, что как проста форт-система в создании, так дополнительно тяжела она в освоении, т.к. все разные

Впрочем можно пытаться высказывать какие-либо рациональные соображения
viewtopic.php?f=2&t=2766
viewtopic.php?f=9&t=2762

Очевидно, что, определив "средние" ожидания, мы выбираем и направление дальнейшего развития и, наоборот, выбрав направление развития мы влияем и на "средние" ожидания. Если, как Вы предлагаете, определять "средние" ожидания без учета этой "диалектики", только на основании рациональных соображений, то возникают закономерные сомнения в их "рациональности". Идет подмена "рациональных" соображений общепринятыми парадигмами, зачастую противоречащим самой сути Forth.
Взять, хотя бы, утверждение: "должен... включать в себя максимальное потенциальное число готовых ассемблерных вставок". Зачем? Чтобы избежать употребления ассемблера в исходниках верхнего уровня? Но, например, в моем проекте этого совсем не надо. Переносимостью у меня и не пахнет (впрочем, эмулированием чужого двоичного кода сейчас никого не удивишь). Зато, очень многие вычислительные куски гораздо проще пишутся на ассемблере, чем с применением изощренной стековой акробатики.
С другой стороны, даже та малая доля нетривиальности, что потребовалась в моем проекте, заставила включить в ядро простенькие средства для построения конечных автоматов. Конечно, мы можем настаивать на включение в "средние" ожидания механизма поддержки конечных автоматов (вон, в Perl полностью машину регулярных выражений зафигачили), но мне-то понадобился не универсальный автоматный компьютер, а, всего лишь, огрызок, явно не способный удовлетворить "средних" ожиданий.
Я - за определение пути к большим проектам, а не за "среднюю" сборку, одинаково неудобную для любого большого проекта.

Бестиповость форта не помешает большим проектам?

Бестиповость Forth не означает бестиповость целевого языка проекта, как "бестиповость" нейронов не означает невозможности человека мыслить о типах и классах.

Форт - метаязык для создания языков предметных областей. Фортер создает свой форт из расчета покрыть свою 'территорию'.
Он расширяет форт с какого-то своего среднего уровня, который коррелирует именно с этой территорией.
Для покрытия территории, которая расширяется по мере ее освоения это годится. Для переориентации на задачи совершенно другой территории как правило(но не обязательно - зависит от задач) надо откатить форт назад к более простому ядру и расширить по-новой. Происходит наработка наборов разных функционалов. Это напоминает 'радиалки' у альпинистов(кто ходил - знает).
Вот программы под windows - тут проще подключиться к чему-то готовому(например к QT). Впрочем если по душе письмо в стиле TCL/TK и требуется минимум окошек, то можно что-то по быстрому сгородить из API напрямую.
Главное, что тут требуется от форта, это быстрота наращивания функционала, при этом желательно, чтобы особенности(узкие места), затрудняющие работу в классическом форте не отсвечивали(не мешали работать максимально эффективно) и были заменены другими приемами без отрицательных эффектов.

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

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

Почему же? Наряду с пессимистическими, но работающими, идеями Дейкстры и Брукса, существует огромное количество идеалистических пособий именно по этому вопросу. От того же Вирта или последних глав Страуструпа, до, не к ночи будь помянутым, рефакторинга...
Сами же пишете:Тут только два нюанса: большая часть этого - шаманские заклинания о ниспослании "серебрянной пули" и ни одна работа не написана фортером.
О каких сложных проектах мы тогда говорим?
Это не так, но к делу совершенно не относится.

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

Про шаманство, мое мнение - мыслительный процесс это основная работа, а не шаманство. Если вы это про работы Дейкстры и Брукса, то согласен - шаманство.
Фортеры(правильные) решают задачи, программирование лишь малая часть в общем объеме работ, не заслуживающая большого внимания.

Сложность проекта - это не синоним объема программы.
Почему? Если все-же так, то к программирования имеет отношение.

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

chess
Я из всего этого понял только то, что Вы считаете, что программирование можно отделить от предварительного решения задачи в голове? Иногда, да. Поэтому я и задумался о том, нельзя ли применить язык программирования не только для кодирования, но и для облегчения умственной работы?
Обидно, однако, за Дейкстру и Брукса, это очень редкие толковые исключения.

И, практически, только в терминах дальнейшего развития.
Утопия. Все изобретатели новых языков так говорят. Однако, никому не удалось создать всех устраивающий.

Только так. Если не так, то нет задачи или есть типовая задача.
Даже математики не думают выписывая формулами, а у них вроде бы было время этому научиться.

Вот это и будет шаманство. Человек не думает словами. Вы хотите его этому научить?
Я их не читал. Поверил вашим словам про их поиск серебряной пули. Наверно не так понял.

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