Which Zend Framework config merge rules create ambiguity for repeatable development environments

Goal is a repeatable development environment for a Zend Framework 3 application using the Composer skeleton, locked dependencies, and a standard module directory layout for modules, public assets and configuration.

ModuleManager loads modules from config autoload paths and merges each module.config.php into a single service configuration used by ServiceManager. Environment specific configuration can be conditionally included via application.config.php and config_glob_paths. Precedence is determined by array merge order rather than an explicit environment hierarchy, and the framework does not enforce a standard container for secrets or environment variables.

The Zend Framework to Laminas Project migration changed namespaces and package names, creating an unresolved decision about remaining on Zend Framework 3 versus migrating to Laminas for continued support. Version assumptions affect repeatability because behavior may differ in the successor.

Which documented merge strategy defines precedence when multiple modules define the same configuration key? Does the lack of an explicit environment hierarchy create an unresolved decision for repeatable local setup? How should the Laminas migration decision be evaluated against repeatability requirements for Zend Framework 3 projects?