Zend ServiceManager shared flag: scope limits with aliases and plugin managers

The Zend ServiceManager, carried forward in Laminas, caches shared services by default, so repeated lookups under the same service name return a single instance, while a service configured with shared => false is constructed on every retrieval. Aliases let multiple keys resolve to one canonical service name, and plugin managers maintain their own scoped configuration for the services they create.

The goal is to pin down the exact scope of the per-service shared flag before relying on it for instance lifecycle control. The uncertainty is which configuration entry is consulted when the requested key and the resolved canonical name differ: the flag may be read from the alias, from the resolved service, or from both, and a plugin manager may or may not override the root container for a service name registered in both scopes.

Specific questions:

• When a service is retrieved through an alias, does the shared setting of the alias key or of the resolved canonical service name govern instance caching?
• If a service name is registered in both the root service manager and a plugin manager with different shared values, which one controls instantiation?
• How does the sharedByDefault container setting interact with an explicitly configured per-service flag?