Это и без Голла понятно, что сложное состоит из простого.
Я и начинал с простого - формата моделей. То, что я не сделал реализации всех промежуточных итераций, не имеет большого значения. Я продумывал концепт и проверял, что он в принципе работоспособный, пусть и в голове. Конечно, при реализации вылезут мелкие детали и подводные камни, но я справлюсь с ними.
У меня есть план составных частей и в каком порядке я буду их разрабатывать. Каждая из них относительно простая и может быть протестирована отдельно.
Я всегда стремлюсь к простоте, а точнее к оптимальному балансу между простотой и функционалом. Большинство существующих решений очень далеко от этого баланса, и именно поэтому то, что делаю я, может восприниматься как серебряная пуля.
Я практически уверен, что реализация моей идеи займёт в разы меньше кода, чем тот же protocol buffers, возможности которого на порядок меньше.

Мне кажется то, что ты делаешь уже есть. По крайней мере я видел такое у Халлидея еще 3 года назад:
https://github.com/substack/bga-format
https://github.com/substack/parse-bga-mesh

а до этого еще где-то

Для хранения мешей сейчас есть много всего, тот же glTF 2.0 довольно хорош. А когда передо мной стояла эта задача примерно 5 лет назад, не было ничего. А та идея, к чему моя первоначальная задача в итоге привела, не реализована нигде.

да норм идея у тебя

Так и слава богу, что появились такие стандарты как glTF, Draco и Basis Universal GPU Texture Codec. А то, каждый игродел городил свои самокаты

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

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

Зачем?

Сделайте компактный бинарный формат со схемой и возможностям храниь отдельные биты и всё.

Смысл делать монстра с ЯП внутри, когда есть обычные ЯП.

Это почти оно и есть. Язык позволит описать всё, что умеет Kantai и больше. Для подмножества языка можно написать кодогенератор. Это отдельная фича, которая будет не сразу, но об этом я тоже думал.

Точнее как раз имеет смысл этого не делать.

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

То есть обычный ЯП?

ну хорошо, функциональный ЯП

Декларативный ЯП с явной динамической типизацией. Таких в мире ещё не существует.

Если ЯП будет сидеть в схеме, то это ещё более-менее норм, хотя избыточно

потому что есть обычные ЯП, которые данные и так сами умеют молотить

если будет внутри сериализовнного представления сидеть ЯП или байткод какой-то