Павел ЛузановТом Лэйн всё http://www.postgresql.org/message-id/3443.1434636106@sss.pgh.pa.us]расставил по местам.он объяснил, почему "она утонула".

но не то -- действительно ли такое поведение ("она тонет") - "правильно".

т.е. это не "расставил по местам".
это "описал причину текущего поведения".
это немного не тот ответ.

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

на сём -- соль ответа: -- можно пользоваться вашими диаграммами, для предсказания порядка срабатывания афтер--обработчиков при наличии "instead" триггеров [и приравненых]. А к системам триггерной репликации впредь подходить осторожно, а не как к гарантированным универсалиям. И работать с ними только разрешенными методами.

Павел ЛузановТом Лэйн всё http://www.postgresql.org/message-id/3443.1434636106@sss.pgh.pa.us]расставил по местам.
ещё раз прочитал нагрёбнутые в кучку аглицкие словеса -- в общем херню он пишет.
"спросите тома, и ваши уши покроются толстым слоем лапши".

он оперирует неопределенным понятием "завершение стейтмента" -- что это такое - никто не знает. предположу, что завершение [в т. ч. обработчиков, если есть] события before последнего row в стейтменте.
тогда прямой вывод -- данная херня есть быть происходить оттого, что разрабцы поленились сообразить, что cte не стейтмент, а мультистейтмент. вернитесь к абстракции стейтмент мультистейтмента -- и всё вернётся на место -- сначала "завершится" (!хехе) последний before sub-DELETE cte -- потом -- пойдут все события after его же - потом before инсерта, внутри которых after для рядков в триггере, потом ... ну, вы поняли. ага. Т.е. какая-то минимальная стройность восстановится. (но есть и там проблемы, кажется, ну да хер с ними).