Рассматривая скобки:
( ) - комментарии
[ ] - переключение между компиляцией и исполнением
{ } - ??, попадались локальные переменные и выделение блоков кода
А если не страдать "синдромом белой вороны", как бы можно было распределить скобки по действиям?

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

Скобки нужны, т.к. выходя за рамки маленьких драйверов и встроенных программ, мы обнаруживаем, что программирование не стоит на месте и изобретено множество способов облегчить жизнь программерам - объектно-ориентированное программирование, разного рода уловки синтаксиса ...
как-то пытался создать свой собственный скриптовый язык, обнаружил, что мне мало 3 разновидностей скобок - для выделения логических выражений хотелось ещё.

Потому можно обсудить их применение традиционное. В С круглые скобки играют роль ... скобок в арифметических и логических выражениях и роль скобок - ограничителей списка параметров для функций и макросов. Это нормально и легко различать, если перед скобками находится слово, предполагающее параметры - то внутри скобок - список параметров, если нет - это выражение.
int function(a,b,c,d ... )

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

поэтому в откртой недавно теме про С-синтаксис я предложил, не трогая чисел на стеке, поименовать их, как если бы это были параметры функций в С - разницы никакой, и там и там на стеке лежат, только в С поименованные, а в Форте по позиции...

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

Комментарии - о скобках сказано, трудно рассчитывать на сочувствие, но скобки нужны для других целей. В конце концов, Форт позволяет создат слово из скобки и
одной буквы
к( начало комментария ...
Комментарий должен отделяться такими знаками, которые никогда не
понадобятся, в С - /* комментарий */

Был замысел сделать так:

: WORD ( A B C )
эквивалентно

: WORD
LOCAL A LOCAL B LOCAL C
TO C
TO B
TO A

С массивами не все так однозначно, потому что вот многомерные массивы должны бы знать свою текущую размерность. Без труда можно организовать слово [], которое по X[] 5 [] даст адрес 5-го элемента массива X[]. Хотя для этого Броуди предлагает писать X[] 5 -TH, что вполне читаемо. Вобщем, квадратные скобки вполне неплохи и в текущей роли.

Для фигурных напрашивается функциональность NONAME: , то есть формирование блока кода, в том числе в тех местах, где по сути требуется одно слово. К примеру, ' { 2 2 + } положит на стек адрес блока кода, делающего 2 2 +

Идея из постскрипта, уже давно мною реализованная

дело вкуса и привычки,
мне вот целиком устраивает
() - коментарий
[] - смена режимов
{} - локалсы
а патаму что нет у меня других привычек
и их я предлагаю не трогать
надо новых выделений? к вашим услугам структуры вида

ну и к слову говоря вспомним про совместимость

Совместимость - это такой интересный лозунг, который вроде есть, но на самом деле его не наблюдается. Иначе не было бы проблем с библиотеками ВООБЩЕ. Совмещаться, к тому же, можно и с наиболее актуальными задачами, и это гораздо полезнее, чем тащить за собой тонны мертворожденного кода. Опять-таки, кодирование есть последний и самый-пресамый ни на что не влияющий этап разработки software. При наличии плана, структуры, требований к программе и документации мало-мальски грамотный программист решает такие задачи явочным порядком.

---

Вообще, мне казалось, хороший тон - коментарии отделять не одиночными символами, а парными, т.к. одиночный символ может понадобиться для оформления логики задания
потому мне понравилось комментирование ( не знаю, чъя идея) (* *)
похоже на С, красиво, симметрично

код - основное , потому ТРАТИТЬ на коментарии столь немногочисленные скобки

Я обычно комментарии пишу после двух слешей:

чтобы не путать с зарэмленными строками и чтобы случайно не раскомментировать,
а всякие чисто отладочные детали убираю табуляцией вправо:

Можно так:
( ) - для циклов, условие проверять на входе и на выходе
тогда:

[ ] - для циклов со счетчиком и автодекрементом (такие проще реализовывать) от какого-то значения до 0
например,
но можно и традиционный DO-LOOP сделать

{ ~ } - условный оператор

Ну а комментарии можно сделать так:

Я в своих поделках чаще всего делаю именно так.

Напрашивается такое решение: по команде ( вызываем встроенный интерпретатор Лисп

А если серьезно, то, например, у тех, кто пишет на Си и его потомках, сложились устойчивые ассоциации:
( ) вызов функции/проверка условия;
[ ] объявление и индексация массивов;
{ } составной оператор;

Вообще мне кажется, что к вопросу реализации комментариев авторы языка подошли слишком легкомысленно, зарезервировав целых 3 односимвольных слова, два из которых - парные! Это слишком расточительно...

К сожалению, слово */ уже объявлено стандартным

А - в чём проблема? Слово /* может просто "ловить" пару символов */, как признак окончания коммента.

С точки зрения безопасного разбора кода, комментарий рекомендуется только один - до конца текущей строки. Многострочные и комментарии в виде круглых скобок в Форте являются потенциальными источниками проблем - кроме неправильного разбора возможен еще и вариант, когда программист неправильно воспримет, что именно закомментировано с точки зрения компилятора.

Проблема может появиться, если понадобится закомментировать фрагмент кода, где используется */
Например, комментируя код A B */ C D, получим /* A B */ C D */, т.е. кусок кода C D */ будет выполнен.
Кроме того, если начнем убирать комментарии, можем случайно удалить команду */, ошибочно посчитав ее концом комментария. Так, например, приведенный выше
фрагмент кода после раскомментирования может превратиться в A B C D */ или даже в A B C D.
Чтобы было похоже на Си, можно сделать:
\\ однострочный комментарий
\* многострочный комментарий *\
Получилось нечто среднее между Фортом и Си.
Впрочем, если в Вашем диалекте Форт */ не используется, то комментарии в стиле Си ничем не хуже любых других.
Также можно реализовать многострочный комментарии в стиле Паскаль: (* *). Это вариант ближе к традиционному комментарию в стиле Форт, но освобождает драгоценные скобки для каких-то более нужных вещей.
Кстати, одиночный символ \ тоже жалко тратить на комментарии, в каких-то языках \ используется, например, для целочисленного деления.