Посмотрите правила вывода в системах типов RDF и OWL хотя бы.

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

Он хотел сказать "декларативное решение", что, впрочем тоже маркетинг, но древний и других людей)

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

Посмотрел
Не понял, зачем это в том же геймдеве)

Из похожих по духу решений лет двадцать назад был популярен UML, но что-то генерация кода по UML не взлетела
Наверное, потому, что усилий по описанию онтологии нужно примерно столько же, сколько написать код, её моделирующий

А чем геймдев принципиально отличается от любого другого моделирования?

Ну, пока его принципиальные отличия от другого моделирования в дискуссии не использовались)

Просто раз уж с него начали

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

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

Аффорданс очередное тупое мутное модное слово/термин, которое можно трактовать всяко, главное напустить туману.

По целям и средствам.
Так часто - цель обозначена, и её цель можно достичь очень разными и очень разнообразными средствами в зависимости от уровня активной моделирующей системы. Умная и знающая система, значит найдет достаточно оптимальные средства.

На текущий момент не интегрирован ВЕСЬ разнообразный опыт моделирования человечеством, НЕ ОСОЗНАН, не формализован. Не хватает времени и опыта, занимаемся этим. Как это будет сделано, так это будет AGI, и будет конец человечеству. )

Людям становится понятно, когда те, кому непонятно, вынуждены понимать или отсеиваться в другие направления деятельности. Вместо того же SQL, собирающего план запроса как уникальное сочетание стандартных алгоритмов, тоже можно "скомпилировать в голове, собрать из говна и палок". Но подобная ручная возня своим объёмом хоронит проекты, поэтому сейчас принято брать СУБД в поддержкой SQL и подобных языков или (иногда) делать решение со своим языком запросов. И это тоже пришло не сразу.

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

Чтобы что-то "заработало в компьютере" у этого должна быть операционная семантика. Операционной семантики is Вы просто никак не обозначили, поэтому и непонятно, что это такое и что оно должно делать.

При этом, из того, что Box123 is HeavyBox && Box123 is VerySpecialBox никаких свойств и никакого поведения Box123 само по себе не следует: нужен ещё механизм 1) задания свойств и поведения; 2) "переноса" свойств и поведения (через is). Пока Вы ничего этого не объяснили — "ничего непонятно".

В данном случае обсуждается не одна конкретная операционная семантика, а сама возможность вывода по "is", которая даже в случае существующих RDF и OWL или ISO 15926 (или Gellish, HQDM, ...) несёт некоторый профит. В моём понимании, профит больше, если использовать стереотипы (как фреймы Минского), но не архетипы. И, тем более, в случае multiple dispatch.

Но сравнение всё равно пойдёт по линии technology stack. Решают работающие языки/фреймворки/библиотеки. Надо ли писать whitepaper независимо от работающей имплементации? Нет.

"Надо ли писать whitepaper независимо от работающей имплементации? Нет." — тогда и обсуждения нет.