nullitte, спасибо за интерес к теме. :)

Вот это и есть одна из частей обобщения того подхода с простыми счётчиками. Ещё более обобщая, вместо счётчиков использовать более сложный набор переменных, которые изменяются по более сложным правилам.

Только всё равно нужна формализация, чтобы исключить возможность получить «ничью». Стандартное возражение: просто при AChan_count > BChan_count переходить к A-chan, а иначе (при AChan_count <= BChan_count) переходить к B-chan, и никакая «ничья» роли не играет. Но для меня так не подходит: формально получается, что читатель выбрал одинаково, например AChan_count=5 и BChan_count=5, а мы забили на равнозначность и перешли к B-chan.

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

А вот это — одна из тех проблем, которых я хочу избежать. Многие проектировщики так и делают — во всех проблемных случаях переходят к плохой концовке и не парятся. Формализация задачи мне нужна для того, чтобы плохая концовка была таким же предусмотренным заранее вариантом, как и любой другой. А не «унитазом», в который сливают всё неподходящее, включая свои же ошибки проектирования. В частности, та же «ничья» может быть слита в плохую концовку. Это подходит многим разработчикам, но не мне. Должна быть не «ничья», а именно предусмотренная структурой выбора плохая концовка (которая набирает больше баллов, чем все эти -chan).