1. Какую технологию? Наверное это технология локального именования. Любая технология может быть расширена или наоборот специфицирована взависимости от задач.
2. Времени на что? Наверное на реализацию и ее доводку и возможные затраты на расширение и специализацию. (два-три дня).
3. Выигрыш в чем? Наверное это выигрыш во времени программирования по сравнению с временем программирования без использования локального именования. Сильно зависит от сложности задач. Чем сложнее задачи, тем выигрыш больше.
Цель, по которой я ввел это расширение, это удаление оперативного контекста из объема внимания за счет исключения манипуляций на стеке, которые и создают этот самый контекст.
Серьезная\несерьезная, игра\не игра - это не существенно, это как рекламный ярлык к вещи.

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

Теперь понятно.
Я беру мое суммарное время работы. Кроме того я выкладываю тексты реализации преследуя несколько целей:
1. Получить реакцию от форумчан на идею и скорректировать ее реализацию по их резонным замечаниям.
2. Показать как конкретную идею можно реализовать. Это может для начинающих быть полезным.
3. Показать работу реализованной идеи на примерах решения конкретных задач.

Отнесем это к субъективным впечатлениям.

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

ps. Отладка свелась к двум пускам программы.

Естественно.

Вот тут я склоняюсь к необходимости очень осторожных рассуждений. Программы пишутся людьми. А в ходе прогресса вычислительных средств их возможности существенно возросли, а стоимость уменьшилась. Тогда как средняя зарплата программиста выросла. В итоге "бутылочное горлышко" при разработке программ неуклонно перемещается от максимально плотного использования ресурсов компьютера к максимально эффективной организации труда программиста. Хотя бы потому, что затраты на зарплату программиста, тщательно следящего за байтами и тактами, существенно больше стоимости этих самых байтов и тактов.

Так и я о том же. Есть ресурсы компьютера и есть ресурсы программиста. Эти ресурсы программиста надо использовать максимально. Идея локального именования позволяет эффективнее использовать такой ресурс программиста как объем оперативного внимания путем исключения оттуда всего, что непосредственно не относится к задаче. Лишним в данном случае является контекст стековых манипуляций, который присущ классическому форту.

Только вот ценой чего достигается второстепенное улучшение? Ценой синтаксиса вида:

Лекарство часом не тяжелее болезни получилось?

Да нет. Стековые манипуляторы тут я не применял.
Стековые манипуляторы это технологический прием, который использует другой ресурс программиста - 'видеобуфер'. Идея видеобуфера 'взята' из языка J.
Общеизвестная статистика о том, что в среднем процедуры содержат 6 параметров. Ну я на всякий случай увеличил это число до 9.
эквивалентно
Здесь видеобуфер это строящаяся строчка 4\412+4*3->
Применять соответсвенно нужно по случаю. Ничего в этом сложного нет. Прямой доступ к параметрам на стеке, которые укладываются в 'видеобуфер' и процесс этот тоже не использует объем внимания.