Не, не те ссылки имеются ввиду.

Контейнер их не будет отдавать. Он их будет резолвить.

Здесь проблема будет только если в не-weak контейнере сделать сервис, который зависит от чего-то из weak-контейнера.

Что сведёт на нет авто-резолв, в общем-то.

Именно, так это сплошь и рядом

смотри, тут вариантов несколько и все под нашим контролем:

В конце, когда мы ожидаем "очищения", всё, что не записано в стейте из С2 исчезнет. Но там останется сервис Б, т.к. он залип в сервисе А.
У нас 2 решения:
- продолжаем выполнение и это скорее всего плохо
- мы сбрасываем воркер (считай все контейнеры) и докладываем о стейте
  разработчик видит это и у него 2 варианта
 * перенести сервис Б в контейнер С1
 * пофиксить сервис А чтобы не было стейта

A -> non_weak С1 -> weak С2 - нет дефинишна, create!
B (A) -> non_weak С1 - тут есть дефинишн. Ссылка на A залипла, weak не почистится.

Ещё, когда мы резолвим А из С1, то мы можем сделать такой режим, что создаваться он будет без контейнера С2 (уверенный режим)
Типа разраб гарантировал, что А - стейтлесс

В общем я предлагал два 100% рабочих решения проблемы. 1 - иммутабельные сервисы, 2 - ResetableInterface. Если найдёте лучшее решение - будет гуд.

Иммутабельные сервисы не всегда возможны, но где возможны делаем.

мои последние 2 сообщения разве не должны были развеять сомнения про жидкий контейнер?

Неа.

Я верно понял?

A -> non_weak С1 -> weak С2 - нет дефинишна, create!
B (A) -> non_weak С1 - тут есть дефинишн. Ссылка на A залипла, weak не почистится.

Нет. Накидай такой контейнер, это в принципе не долго, и ты сам все увидишь.

Пример этого - stateless-класс без интерфейса SmsSender, без конфига.

создавая сервис из С1 мы можем уверенно резолвить зависимости из С1

В варианте с weak либо он залипнет (если от него что-то зависит в non-weak, либо будет пересоздаваться постоянно. И то и другое не очень хорошо.

Мы уже столько времени, включая прошлые разы, потратили на обсуждение, что давно можно было проверить)

Ну так и делаем. Только  A  нет в C1, она в C2.