Можно меня записать.
Мои предложения:
Код слов низкого уровня в бинарном формате. Причина: можно каждому участнику использовать свои ассемблер (Форт-асм, FASM, MASM и пр.)


ЦК на форте. В кач-ве форта, на котором пишется ЦК предлагаю использовать Нову т. к. уже из коробки можно подключать файлы в бинарном виде и адресовать исходники от ранее использованных файлов. Т. к. я разраб Новы, лучше заморочиться ЦК мне. Или можно СПФ

Слова высокого уровня на Форте

По внутреннему устройству:
Предлагаю минимум: стек словарей, одна цепочка поиска слов, пользовательских переменных нет.
Кодогенераторы отдельное поле в словаре, т. к. расширяемей

Связь с WINAPI на х64 предлагаю взять себе.

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

Что уже не получалось. Прежде всего, несколько раз проваливались попытки написать "новый стандарт", "стандарт RuFIG", и прочие стандарты. Причин много - самая частая была в стиле "а я вот хочу слово BLUMP и без него ничего делать не буду, а как оно работает и зачем - присоединяйтесь и узнаете". В то же время основные вопросы для практического обсуждения обычно лежат не в сфере "какие слова сделаем", а в прояснении таких вопросов, как работа с памятью, файловой системой, таймерами, сетью и прочим, что напрямую к Форту не очень относится, зато помогает написать его реализацию. Можно долго спорить, как конкретно следует сделать словари (и все равно каждый сможет сделать как ему надо, а значит, сделает), но вот спорить по поводу того, как в какой-то ОС открывать файлы попросту бесполезно.

Отсюда вывод. Начинать совместную работу необходимо со скучного на первый взгляд, но на самом деле полезного занятия - проектирования системы. Эту работу легко низвести до полной ерунды, занимаясь рисованием квадратиков и стрелочек и выписывая "хотелки", тогда как правильно сделанный проект архитектуры позволяет легко и просто написать рабочее ТЗ, дающее свободу для реализации. Как это делается - можно смотреть соответствующие материалы, включая стандарты. Там есть много интересного.

эх....я б и ввязался....но в х64 ни-в-зуб-ногой....

На Си вообще проблем не заметно, на ассемблере вместо eax пишется rax (и далее по аналогии).

Но я-то вижу проблемное место не в том, как закодировать, а в том, как написать спецификацию и "расставить причинно-следственные связи". Я имею в виду набор утверждений вида "чтобы работало то-то, нужно реализовать вот это".

Там, в принципе, к операциям с регистрами добавляется префикс
И иначе работают некоторые инструкции вида.