I have to agree part of me wanted this as well. In fact I raised it with you on the forums, in which you thought it was a bad idea.
The problem I see is that here is a stock standard module, ForgeBox. It is supposed to work out of the box and it doesn’t. This is because I moved all my handlers and views etc., into categories for this application.
To help explain this a bit more, before you introduced modules I was looking at my own method of implementing it. Which went along the lines of this as far as conventions goes.
Wwwroot
-system
-user
Under System I would hold all the functionality that was going to be to have the base system work, such as the handlers, views etc. In the user directory this was going to be any plugin/module to the system to enhance the application beyond the system.
So basically, I could define a user view that overwrote the system view by redefining the layout or the view to give it a different look and feel or functionality. I can still see this working, but I am excited about modules because it sort of helps were I wanted to go.
But I don’t feel that the full directory path system.module.handler should be inherited by a module, because it means I can’t just plug it in with serious modifications, I do think that the last directory in that path can be used for the convention definition just not the full path. Unless it is changed, by the user in the modules own convention path.
One thing that I was thinking about is that maybe, by default the module follows the standard convention which is what ForgeBox can be used as a guide here. If I write a module and want to inherit the parent application, then maybe I can have a setting that would do this. As well as a config setting in the moduleconfig to look at as well.
Hopefully that makes some sense.
I am thinking the order could be default to standard convention, then parent convention and last but not least overwrite by adding the convention to the module config file.
Thoughts?