На диаграмме 1 из State1 по событию b произойдет переход в State2.
На диаграмме 2 из State1 по событию b произойдет переход в State3.
А куда и почему произойдет переход из State1 по событию b На диаграмме 3?

Это головоломка? Чем отличаются диаграммы 1 и 2?

Условия переходов из choice проверяются на момент входа в него, переменная А к этому моменту имеет значение 1.
Условия переходов из junction проверяются на момент выхода из настоящего (не псевдо) состояния, переменная А к этому моменту имеет значение 0.
Строго по этим правилам в диаграмме 3 произойдет переход в State3. Но это как-то неестественно (подряд два перехода с одним и тем же условием, но по одному идём, а по другому - нет).

Главное – не использовать такие картинки в реальных проектах.

А куда и почему произойдет переход из State1 по событию b На диаграмме 3?

Если трактовать переходное псевдосостояние, как спец. обозначение для более удобной записи переходов и сторожей, то для ответа на вопрос, нужно переписать диаграмму без спец. обозначения. Получаем:
<>--[a=1 and a=1]-->State2
и
<>--[a=1 and a!=1]-->State3
Ответ: State2.

трактовать переходное псевдосостояние, как спец. обозначение для более удобной записи переходов и сторожей

Класс! Я только чувствовал, что так должно быть, а теперь получил и обоснование.
К сторожам можно добавить триггеры и действия на переходе (более удобной записи переходов: триггеров, сторожей и действий). Триггер не более, чем 1 на всей цепочке переходов через junction, выходящей из состояния (для остальных цепочек триггеров не может быть).
Цепочки переходов через junction не могут быть циклами (через choice могут!).

Проблема стандарта в том, что эти вершины-псевдосостояния и звенья-псевдопереходы для авторов стандарта как бы заслонили тот факт, то [настоящая] диаграмма состояний описывает табличку [настоящих] переходов между [настоящими] состояниями.  В результате метамодель в части конечных автоматов описывает не автомат как таковой, а некий граф, из которого может быть выведен [настоящий] автомат в том случае, когда граф построен по правилам. Но описать правила построения графа и правила вывода из него автомата стандарт не берётся.

В результате метамодель в части конечных автоматов описывает не автомат как таковой, а некий граф, из которого может быть выведен [настоящий] автомат в том случае, когда граф построен по правилам.

По-моему так и надо, если:

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

Но описать правила построения графа и правила вывода из него автомата стандарт не берётся.

Берётся, но не достигает.

Берётся, но не достигает.

Имелось в виду, что там не придаётся внимания тому, что за графом лежит ещё один слой "таблички", почти не отличимый в простых случаях, и требующий вывода в сложных. Наоборот применяется растушёвка: вершины стабильные и нестабильные; звенья/переходы/составные переходы.

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

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

Вот ещё пара копеек про составные переходы.
Примеры с псевдосостояниями выбора обычно таковы, что эти псеводсостояния находятся на одном уровне с состоянием-исходом и целевыми состояниями. Придумаем [довольно бессмысленный] пример, где будет по-другому. В "матрёшке" композитных состояний расположим псевдосостояния выбора на разных уровнях. Приправим блюдо действиями по входу и выходу. Получится что-то вроде приложенной картинки.
Что мы видим? Что псевдосостояние выбора это "синтаксический сахар". Заменим мысленно все ромбики на разрезающие составной переход на части обычные состояния [переходы из которых будут происходить по событию завершения]. Работать обновлённая машина состояний будет также.
Но "синтаксический сахар" у нас странного свойства. Представим, что в каждом ветвлении у нас "плохой" набор условий: вместо [guard] и [else] -- [guard1] и [guard2], которые могут быть одновременно ложны. Диаграмма с псевдосостояниями выбора становится ill formed, а с аналогичными обычными состояниями вполне себе "well formed". При чём well formed диаграмма будет "зависать" также, как ill formed. Ей почему-то это разрешено.
Что в итоге? Выявлен элемент нотации, обогащающий язык единственным дополнительным смыслом -- лишним запретом.

Продолжим эксперимент. Заменим все choice на junction. После этого перестаёт иметь значение то, где расположены псевдосостояния. Только что это было важно, а теперь перестало быть важным. Но то, границы каких состояний пересекаются звеньями, осталось важным, хотя и по-другому. Заметим, что метамодель UML позволяет точно отслеживать только расположение состояний и псевдосостояний. Узнать о пересечении переходом границ состояния, влияющем на выполнение действий по входу/выходу, можно только с диаграммы.

Если имеются состояния, все переходы из которых будут происходить по событию завершения, и выполняется условие, что хотя бы один переход сработает ("хороший" набор условий), то такое состояние может/должно быть заменено на choice. Из выгод от этого пока вижу только одну: глянув на диаграмму с choice сразу видно, что "устойчивых" состояний только 5. На диаграмме без choice необходимо вчитываться (всматриваться), чтобы определить, что 4 из 9 состояний - неустойчивые.

Заменим все choice на junction. После этого перестаёт иметь значение то, где расположены псевдосостояния. Только что это было важно, а теперь перестало быть важным. Но то, границы каких состояний пересекаются звеньями, осталось важным, хотя и по-другому.

не понял

Заметим, что метамодель UML позволяет точно отслеживать только расположение состояний и псевдосостояний. Узнать о пересечении переходом границ состояния, влияющем на выполнение действий по входу/выходу, можно только с диаграммы.

В метамодели Transition имеет обязательное значение container:Region. Оно должно подчинять и вход и выход, и именно по цепочкам до него происходят пересечения границ сначала изнутри-наружу, а  потом снаружи-внутрь.

Радо новой встрече.

Написанное справедливо при обратной замене состояний, заместивших собой choice'ы. В общем случае замена на choice возможна не всегда. Choice одновходовый, а "неустойчивое" состояние может иметь столько входящих переходов, сколько нужно (в том числе рефлексивные), а также действия по входу и по выходу, которых choice лишён. Отметим момент: что если бы вместо choice имелась возможность метить состояние как неустойчивое ("зависание" в котором = ill formed)? Было бы выразительнее, не находите? Замещающее choice "неустойчивое" состояние может не только его имитировать, но и описывать более сложное поведение.

С junction'ами все действия по выходу выполняются после проверки сторожевых условий, составленных из условий-частей на звеньях, составляющих композитный переход. А действия по входу -- после выполнения композитных действий по переходу, составленных из действий-частей на звеньях. С choice'ами условия-части проверяются "динамически" (цитирую стандарт), т. е. перед проверкой будут выполнены некоторые действия по выходу и действия-части на ранее пройденных звеньях. Поэтому расположение junction'ов неважно, но важно пересечение звеньями границ состояний. Например, два нижних junction'а можно поместить в St01, а два верхних -- в St0. Смысл диаграммы не изменится, т. к. звенья сохранят свою топологию. Перемещение choice'ов изменит поведение автомата. Также поведение изменится, если звено выгнется и пересечёт дополнительно какую-то границу.

Про регион-владелец стандарт пишет странное (мы уже обсуждали). Можно заметить, что на диаграмме абстрактного синтаксиса из метамодели UML у перехода нет владельца, но есть... контейнер. Далее контейнер и владелец объявляются синонимами.) Рекомендованным стандартом контейнером-владельцем является расположенный глубже всех и содержащий вершину(ы)-начало(а) перехода и вершину(ы)-конец(цы). В нашем примере стандартным владельцем будет регион состояния St0. Это не позволяет где-либо кроме как на диаграмме увидеть, что переход пересекает границы St0.

Радо новой встрече.

Я тоже!

Choice одновходовый, а "неустойчивое" состояние может иметь столько входящих переходов, сколько нужно (в том числе рефлексивные), а также действия по входу и по выходу, которых choice лишён.

Choice может иметь и несколько входов [стандарт 14.5.6.6: "In a complete statemachine, a choice Vertex must have at least one incoming and one outgoing Transition.
inv: (kind = PseudostateKind::choice) implies (incoming->size() >= 1 and outgoing->size() >= 1)"], в том числе (в отличие от junction) и рефлексивные как раз за счет того, что "С choice'ами условия-части проверяются "динамически"".
Что касается действий по входу и выходу:

• они являются "синтаксическим сахаром"
• по входу могут быть обозначены с помощью junction - все входящие переходы не в choice, а в junction, и один переход (сегмент) из junction в choice с необходимым действием. Возможно и для действий по выходу можно что-то придумать

С junction'ами все действия по выходу выполняются после проверки сторожевых условий, составленных из условий-частей на звеньях, составляющих композитный переход. А действия по входу -- после выполнения композитных действий по переходу, составленных из действий-частей на звеньях. С choice'ами условия-части проверяются "динамически" (цитирую стандарт), т. е. перед проверкой будут выполнены некоторые действия по выходу и действия-части на ранее пройденных звеньях. Поэтому расположение junction'ов неважно, но важно пересечение звеньями границ состояний. Например, два нижних junction'а можно поместить в St01, а два верхних -- в St0. Смысл диаграммы не изменится, т. к. звенья сохранят свою топологию. Перемещение choice'ов изменит поведение автомата. Также поведение изменится, если звено выгнется и пересечёт дополнительно какую-то границу.

Спасибо, мне стало понятно.

Рекомендованным стандартом контейнером-владельцем является расположенный глубже всех и содержащий вершину(ы)-начало(а) перехода и вершину(ы)-конец(цы). В нашем примере стандартным владельцем будет регион состояния St0. Это не позволяет где-либо кроме как на диаграмме увидеть, что переход пересекает границы St0.

Есть версия, что стандарт ошибается, говоря про "глубже всех", годится любой, содержащий начало и конец. В примере (для [guard2]/act2) это регион, описывающий весь автомат (по стандарту каждый регион относится или к какому-то состоянию, или к автомату вцелом)