laminas-mvc 3.x and laminas-servicemanager 3.x: who adapts ServiceLocatorAwareInterface to PSR-11?

laminas-mvc 3.x pairs with laminas-servicemanager 3.x, whose container implements PSR-11's ContainerInterface while the framework-specific ServiceLocatorInterface is deprecated. Many existing modules still pull dependencies through ServiceLocatorAwareInterface and its accompanying trait, so the upgrade friction sits exactly at this integration boundary.

The reported friction point: ServiceManagerFactory in laminas-mvc 3.x no longer injects a locator into ServiceLocatorAwareInterface implementations, and the deprecated ServiceLocatorAwareTrait only cooperates with containers that still expose the legacy interface — which a PSR-11 container does not. No official adapter or migration tool bridges this gap, so each legacy module must either be refactored to factory-based wiring or wrapped by hand.

Assuming laminas-mvc 3.x with laminas-servicemanager 3.x — exact patch versions should be confirmed against the release notes and the ServiceManagerFactory source before planning — the design decision remains open: should the MVC layer detect ServiceLocatorAwareInterface and wrap the PSR-11 container in a compatibility proxy, or enforce strict PSR-11 compliance and leave adaptation entirely to module authors?

Which direction fits the project's deprecation roadmap: a built-in container proxy, or strict PSR-11 with per-module adapter factories? And for third-party modules untouched since before PSR-11 adoption, is a hand-written adapter factory the only supported bridge short of forking?