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

Почему же так?

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

Ну лан, раз так

Ну а как тогда? Он же направляет на роут, вызывая невно рендер. И по этой же логике получается, что он рендерит, хоть и неявно)
Если не пустит на роут - значит не зарендерит)

А Гард не явно ли вызывается роутером?

Вот вот) Получается подмена понятий)
Инициировать - не равно делать

Ну тут вся дискуссия на этом строится)

Я все же за это топлю

Ну в общем, не холивара ради)
Я же свою позицию последовательно объяснил от основы ООП, где мы выделили абстаркции, а за ними объекты, описал принципы которыми мы руководствовались. И по этим же принципам пришел к заключению, что все каноны соблюдены. Также отметил, что есть в этом элемент субъективности (вот как раз на уровне абстракций). Возможно и расхождения из-за этой субъективности, но на мой взгляд, проблема в подмене понятия "вызывает" на "делает". Это не одно и то же. Если мы будем исходить из "вызывает" = "делает", не обращая внимания на то, что у нас сущности разделены по канонам, получится что все наше приложение - выполняет все)
Но мы же понимаем, что это не так)

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

Опять же, не холивара ради)

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

Я не настолько продвинутый оратор как Александр, но я пожалуй тоже выдвину пару моментов как финальный бросок себя в уже открытую могилу:
Ну ваще я буду краток, и немного пройдусь по-кругу:
За кипиш:
1) То что в гуарде содержится логика отображения - не очень хорошо.
Не вижу разницы между: document.getElementById().appendChild()
И
LibName.openDialog()
2) подвязка гуарда на стороннюю библиотеку для юая заставить переписывать и логическую часть приложения (коим гуард и является). Приходится смешивать
3) монтирование компонента из гуарда заставляет иметь задекларированный компонент в скоупе, хотя для большинства гуардов это и не нужно.
+ иметь независимый код от наличия browsermodule/commonmodule для бизнеслогики, без инжектинга ненужных зависимостей в нее - меньше эффорта в будущем для миграций, меньше места для легаси-кода.
4) если стараться добиться максимальной индексации контента поисковыми роботами, то желательно чтобы все состояния приложения (в тч. Модалки) были доступны по урлу, а код который меняет индексируемый контент в гуарде путем отрисовки модального окна - не лучший выбор. Особенно, если речь заходит о SSR
5) шина сообщений доступная во всех контекстах приложения выглядит найс потому что можно отследить хронологию событий на своей стороне. (Не знаю как выразить точнее).

Минусы:
1) придется написать один дополнительный сервис и заинжектить его в корне приложения. Брр....

Да, возможно каждый пункт из этих содержит внутри себя уйму логических ошибок, и ваще кг/Ам.
Но опять же, дело вкуса. Я конечно ещё тот эксперт,  мне кажется что @drxwat, например, в этом вопросе более подкованный

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

Пасиб @drxwat !

Ок, альтернатива понятна. Как по мне имеет право на жизнь и понятна логика такого разделения. Комментировать подробно не буду - займет много времени. Скажу лишь, что я бы все-равно заюзал свой вариант как более лаконичный и без нарушения канонов.
Спасибо за подробный ответ и за дискуссию) Не хотел никого обидеть, если что)

Это было круто

Несколько лет спустя создания чата, он сработал как в моих мечтах!

Люблю вас