Thank you for reporting this bug. We will make it our priority to review this report.
We chose the singular approach because it matches our class naming conventions. Each of those directories maps to a package namespace, e.g.:
MyApp.model.User vs MyApp.models.User
MyApp.view.user.Edit vs MyApp.views.users.Edit
We never pluralize package names in the framework and want application code and framework code to feel as alike as possible. By keeping to these naming conventions we can leverage our strong class model and tooling to make applications easier to write and deploy.
Ed can you speak a little about what happened to the routing functionality in prior revisions of MVC?
Absolutely. We tried hard to make this server-inspired pattern work on the server but have had to rethink our approach. I think we have a great solution lined up for deep linking and application-wide history management lined up but we decided to push it to 4.1 to be sure that we could deliver the right solution. Turns out it's not quite as simple as we would have liked...
Originally Posted by ykey
The great thing about what we have in 4.0 though is that it's only 3 classes, yet delivers an enormous amount of power. I love writing apps with this stuff
Simplicity is great but I would rather have to worry about 5 classes and have the routing and history management. The routing functionality becomes very important with larger applications (especially direct navigation to secondary screens to accelerate development). I had experimented a bit with the functionality you had and it seemed promising but I am sure there are complexities I have not considered.