Actually I believe what he was looking for has more merit than people think, the downside comes about with plugins and models, that are DI’ed and used as singletons. But I don’t think that would be a massive problem overall.
First lets look at handlers, he wanted to know if it was possible that if the handler was in the external handler, could that be called over the standard handler. This has more merit, because it allows for core handlers to work, and if there is one in the external location then that is used instead.
I didn’t do this much with handlers myself, as I didn’t see a huge or great need for it. But I did use it on the odd occasion, and like any good OOP I could extend the standard location from the external to provide the missing pieces without falling to the DRY problems that can happen.
I might be wrong, but I believe this is the approach and method he is trying to tackle. Like I did around 3 or so years ago.
In the end due to how much the RC changed, I found it quicker and dirty to create empty handlers that just was empty and extending the original, because it was quicker and easier to do this than rewrite the constant changes of the RC decorator.
So my files quickly grew, and it is also why I maintained that I wanted separation of entities and services. Because my entities had the same fate, empty files that extended the origianal and services that did the same. My files grew very fast and CF ended up choking a lot of the time, because of the amount of files that had to be searched by CFORM.
Now its not very often that someone is going to design a site like this, but I have now worked with 4 different clients that I used this approach on. The biggest was when the code base or core application, had around 35 domains pointing to it and it kept growing. But each site had very similar modules, yes this was designed in the days prior to modules, but even today modules will suffer the same problem due to the look and feel or different functionality needed for the handlers etc.