Это для других целей, подключение коллектора логера идит в другом месте. Да и на его места можно передать другой коллектор, например ивент коллектор и он не будет работать, хотя интерфейс соответсвует, так что там однозначно надо было менять или на отдельные интерфейсы или на конкретные реализации.

Не вижу смысла обсуждать, пока не выложу ПР, поскольку там уже все сделано.

вот смотри, сейчас в мастере лежит пакет, который работает, но с изъянами по управлению зависимостями и конфигурированию. твой PR не одну из проблем не решает, просто дробит все еще сильнее. зачем его лить в этом случае я не особо понимаю.
мысль с разбивкой интерфейсов имеет место быть, если ее правильно организовать до конца, а не как сейчас.
не думаю, что кому-либо еще понравится всё то, что сейчас ты скинул в тот ПР, соответсвенно, пр на закрытие, а старания на ветер.
вместо необдуманной и не особо планированной работы, ты бы мог запилить уже вьювер, например

Результат примерно так выглядит в коллекторе.
https://i.imgur.com/Zno3IX4.png

Но там и кроме коллектора есть фичи.

В ПР дебагера не было проделано никакой существенной работы. Более того, я в процессе разработки еще немало вариантов пробовал. А с интерфейсами, я их оставлю, но верну старт/стоп. Так что насчет закрытия говорить рано.

а говоришь конечная версия)

Конечная в том смысле, что я не буду туда исправлений вносить, только верну как было. Я кроме интерфейсов все остальное только для обсудить делал.

с интерфейсами я про то, чтобы стабилизировать метод collect(). чтобы уйти от плавающих аргументов к статическим и описанным в доке

это ты здесь ловишь всё, что отдается в get и оборачиваешь в класс для трекинга дальнейших действий с объектом?

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

Детализация (здесь максимальная стоит) и отслеживаемые интерфейсы настраиваются в конфиге. В целом да, ловится все что в гет и если оно в списке трекинга то автоматически создается пркси-класс для дальнейшего трекинга объекта.

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

это в params.php tracked_services для него создано?

Это для демонстрации старта дебагера без прописывания его в index.php. То есть, если стоит прокси, то просто делаешь require yiisoft/yii-debugger и он будет автоматически запущен если включен в настройках.

То есть, сервис провайдер в контейнере при этом не добавляется.

Причем здесь вообще коллектор? Это прокси. Такой же как и твои LoggerProxy and EventDispatcherProxy, но с дополнительными фичами.

оформи эту штуки в виде прокси и давай зальем ее в yii-debugger, эта крутая фича будет

Как раз прокси из дебагера уедут в отдельный пакет и там вместе с этим пркси и будут. Ну я так это вижу.

только вот конфигурирование надо бы сделать простым, что-то вроде такого:
interface1=>3,
interface2=>5
где 3  и 5 это уровень, который будет где-нибудь описан