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

Эх, сча бы от тайплевел гарантий отказываться

Сударь, вы просили не писать вам.
Это затруднительно при условии, что вы пишете мне)

consumer должен понимать время жизни подписки. Если допустим после нажатия кнопки создается подписка, и внезапно туда стали приходить очень долго изменения это не оч. И от этого лучше защититься

consumer должен понимать время жизни подписки. Если допустим после нажатия кнопки создается подписка, и внезапно туда стали приходить очень долго изменения это не оч. И от этого лучше защититься

Не лучше ли всё-таки возложить эту ответственность на продюсер и принять за правду на уровне консьюмера, что она решена?

Ну и получается неявное эмпирическое поведение, а между прочим единственность ивента может быть частью контракта

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

если меняется бизнес-требование - меняется контракт, всё нормально

Мой подход - обрабатывать логику, описанную @Bouxroix и ее граничные случаи на уровне продюсера( router, interactor).
Таким образом на уровне консьюмера впринципе не фигурируют частные случаи наблюдаемых.
Я от них стараюсь абстрагироваться. И в случае того же изменения ТЗ, мне нужно выполнить изменения только в логике, данных. Адаптерам и фреймворк уровню плевать. Пришла 1 нотификаций - обработали 1 раз. Пришло Н - обработали Н.
Но да, в контексте типизации я теряю информацию. Вопрос в том, нужна ли она.

Консьюмер может создавать подписку по большому счету в двух местах. В самом начале или по какому то событию (нажатие кнопки). Он должен понимать как именно это делать. Есть есть разные типы это очевидно. Если тип один и как то по названию, ненадежно. Продюсер ничего не знает о консьюмерах. Легко можно что то забыть и при изменении их затронуть

Мой подход - обрабатывать логику, описанную @Bouxroix и ее граничные случаи на уровне продюсера( router, interactor).
Таким образом на уровне консьюмера впринципе не фигурируют частные случаи наблюдаемых.
Я от них стараюсь абстрагироваться. И в случае того же изменения ТЗ, мне нужно выполнить изменения только в логике, данных. Адаптерам и фреймворк уровню плевать. Пришла 1 нотификаций - обработали 1 раз. Пришло Н - обработали Н.
Но да, в контексте типизации я теряю информацию. Вопрос в том, нужна ли она.

А тесты вы пишете?

Обижаете)