Роутинг для iOS: универсальная навигация без переписывания приложения

Судя по демо-проекту у вас транзишн привязан к конкретному контексту, соответственно ViewControllerContextTransitionProvider выглядит спорно, в большом проекте switch станет огромным. Похожая ситуация с ViewControllersByContextFactory, только тут switch будет еще больше.

Возможно имеет смысл создавать отдельную реализацию для каждого ViewControllerContext, которая будет хранить в себе всю необходимую информацию о переходе. Количество файлов в проекте вырастет, но зато мы получим тайп-сейф инициализаторы контекста, конфигурация контроллеров будет инкапсулирована внутри контекста, плюс отпадет необходимость в реализации ViewControllerContextInfo, энума ScreenType, который в реальном проекте может может иметь 50+ значений; исчезнет огромный switch из ViewControllersByContextFactory.

Что-то вроде этого:

protocol ViewControllerContext {
    
    var transition: ViewControllerContextTransition { get }
    func prepareController(using resolver: ContextResolver) -> UIViewController
}

struct ChatViewControllerContext: ViewControllerContext {
    
    let chatId: String
    let transition: ViewControllerContextTransition = NavigationControllerTransition()
    
    func prepareController(using resolver: ContextResolver) -> UIViewController {
        // ContextResolver – абстракция над вашим DI-контейнером etc.        
        return ChatViewController(chatId: chatId)
    }
}

А методы свитчера и холдера будут иметь generic-спецификацию:

protocol ViewControllerContextHolder {
    func hasSameContext<C: ViewControllerContext>(as other: C) -> Bool
}

protocol ViewControllerContextSwitcher {
    func canSwitch<C: ViewControllerContext>(to context: C) -> Bool
    func switchContext<C: ViewControllerContext>(to context: C, animated: Bool)
}

Dagger 2. Subcomponents. Best practice

Смысла хранить сабкомпоненты экранов я не вижу в принципе, время жизни таких компонентов равно времени жизни активити/фрагмента.

К ListComponent как раз таки должен обращаться только фрагмент. Остальные зависимости данного скоупа ничего знать про компонент не должны, соответственно, в адаптере собственного метода inject() тоже быть не должно. Все его внутренние зависимости можно предоставить либо через модуль, либо повесить Inject на конструктор + методы/филды.