This is one of the things you can't fix in the MVC layer (and truthfully a fair bit of the API) without B/C breaks. The places in the API taking config arrays as constructor arguments aren't well suited for DI oriented code, those are places where you'd still need to direct instantiate the class and manually search for or build dependencies (you can't do $container->get() for a defined service or $container->buildObject() to autowire something because you can't make that config array a container value).

So you've really got a few options:

• Accept the classes can't be DI'd and use the container as a service locator
  • Generally accepted as a bad practice, but gets the job done
• Require some kind of middle layer factory that creates the classes and uses setter injection to push dependencies after the class is instantiated
  • Complicates the API, objects get created in invalid state
• Formulate a plan to break the hard reliance on the config arrays, deprecate existing constructor signatures, and move classes to DI oriented approaches
  • Long term B/C implications, probably has implications on how some classes are configured, but similarly gives us a chance to re-evaluate the base MVC class designs and determine what bits and pieces belong in a config array and what could/should be done through more explicit configuration as setter methods or explicit constructor dependencies