Это декларативный подход, где элемент завязан на текущее состояние. Почему

костыль то?

В данном случае, чисто из-за визуальных аспектов

это тут не причем, просто от самой формулировки, в которой экран должен сам определять как-то, должен быть там виден боттом бар или нет тошнит)

А как иначе? Сформулировать это можно с разных сторон - на уровне BottomNavigation решается, должен ли быть бар на конкретном экране, или экран через какой-нибудь Controller говорит, нужен ему бар или нет, суть от этого меняется не сильно Если состояние бара определяется разными NavHost, и внутри одного из них экрану в какой-то момент вдруг понадобится бар, а его нет - что делать? Не переписывать же половину навигации Создать List<Route>, в котором перечислены экраны, на которых нужен (или не нужен) бар - простое, но очень статичное решение. Если вдруг появится экран, в котором бар может появляться и исчезать, существующее решение будет не так-то просто подтянуть под новые требования Какие ещё варианты?

RootContent: Scaffold( content = { NavHost(…) }, bottomBar = { BottomNavigation(…) } ) Если надо где-то скрыть, чайлд пробрасывает наверх родителю сигнал, что нужно скрыть боттом бар. Все)

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

ну я думал там используются какие-то костыли, а не простой калбэк например)