А как быть если после некоторых состояний необходимо пройти через определённую цепочку состояний, а затем вернуться к исходной цепочке? И так - в разных местах.
состояние1
состояние2
состояние10
состояние11
состояние12
состояние3
состояние4
состояние5
состояние10
состояние11
состояние12
состояние6
...

Ваш пример похож на последовательность выполнения строк на бэйсике, соответственно используется что-то типа GOSUB
Ну и объединить цепочку состояний в одно состояние с дополнительным индексом ничего не мешает.
Регулярность и простота автоматов - хорошо, но все же иногда нужно немного и усложнять реализацию.

Объединить? А что тогда мешает объединить все остальные состояния автомата в одно? Если ничего - то и автомат не нужен, так как всего одно состояние осталось. А если есть автомат - значит он для чего-то нужен и нельзя объединить состояния.
А если нужен доплнительный индекс, то как потом возвращаться к основному? А если не один уровень вложенности, а больше? Стек хранения состояний городить?

Почему это нельзя объединить? Ну не будьте уж таким догматиком. Одну и ту же задачу могут выполнять автомат с одной переменной состояния, которое может принимать, допустим 16 значений и фрагмент программы, использующий 16 битовых флагов. И выглядеть они будут похоже, всего вместо case будет if, ну и присвоение чуть по другому.
А между этими двумя реализациями целый диапазон возможных решений.


Усложняете. Вот кода, описывающего одно состояние с дополнительными промежуточными состояниями проверки индикации.


Что касается стека... Стек, не стек, но что мешает запоминать предыдущее состояние и при необходимости туда возвращаться? Если интерфейс пользователя - один большой автомат, некоторые функции вызываются из разных меню, возвращаться нужно именно в предыдущее состояние. Можно назвать это одноуровневым стеком.

Вот и дошли до того, что при создании реальных автоматов стек состояний (как бы Вы его не назвали другими словами ) тоже можно и нужно использовать. Что тоже уменьшает безмерное разрастание состояний. У меня почти уже в привычке использовать в минимальной "базе" три состояния - текущее, предыдущее и то, на которое сейчас текущее будет измененно. Так же огромное знвчение стека в диагностике работы в РЕАЛЬНЫХ условиях - как дошли до ошибки.

А как Вы заглядываете в будущее оперируете с этим значением ?
У меня обычно просто - присвоил текущему и вышел, а анализ смены состояния в начале вызова обработчика автомата.

Конечно ничто не мешает. Только код становится уже плохо читаемым, слишком громоздким с такой реализацией на классических автоматах.
В этом случае я делаю псевдозадачу (которую можно считать к.автоматом). Только она не вытесняется принудительно другими задачами как обычная задача ОС, а вытеснение задачи происходит по логике её работы, при переходе к очередному состоянию автомата. А состояния автомата при этом - это значения PC, которые сохраняются в стеке при вытеснении задачи и на которые происходит переход при активации задачи. И код становится читаемым даже при наличии сложных ветвлений и вложенных состояний автомата.

Хотим изменить текущее состояние автомата - "будущее" это то значение на которое изменим. "Прошлое" это сохраненное котрое было до текущего.

А присвоение текущему уже в конце обработчика - так и правильнее, ибо состояние сменилось, когда ВСЕ действия сопутствующие смене состояния уже произведены.
Таким образом в процессе переключения типично известны ТРИ состояния прошлое-настояшее-будущее.

Тоже согласен, что если состояний больше десятка(а зачастую это штук 5) - значит что-то делаете не так. Это касается также и FPGA.
Задачу надо дробить на более простые, а не сливать все в одну кучу. Вот показали бы реальную задачу реализованную на 100 case-aх, я бы показал как ее реализовать гораздо проще.