MVC file systems reexamined

A conventional file structure has emerged, bolstered by Ruby, Zend and other systems, that I find cumbersome: 

• Create a single file for each controller in the "controllers" directory.
• Create an action function for each action in the controller file/class of each controller file. 
• Create a views folder, and a subfolder for each controller within that, and a view file for every action within that. 
• Create a models folder with a file for each model somewhere else. 

What that means is that the resources for a given action are scattered throughout the MVC file system, and the contorller is a bloated, frequently edited mess, which forces complex merges when a project goes into heavy development. 

Why not, instead, organize the file system around centrallized controller directories?

Say you have a user controller with actions get, put, post, find, and login, and a blog controller with get, put, post, find, publish, unpublish and list?

Wouldn't the following file structure be more convenient? (BTW as a noder I'm using the .js file suffix - but this argument is not server side language dependant and should hold true for ruby, python, java, et. al.)

app
  parent.js
  _index
    action.js
    view.html
  users
    parent.js
    model.js 
    _index
      action.js
      view.html   
    _get
      action.js
      view.html
    _put
      action.js
    _post
      action.js
    ...
  blogs
    index.js
    model.js
    _get ...
    find...
        

(I'm assuming that put and post all redirect to _get, and require no views)

In this system, the resources required to comprehend an action are all in either the same folder or at worst, one or two parents up. 

Implicit REST responses are underscore-notated in that there is no path "/users/get" per se, just a handler for GET "/users/id". 

Actions are at the end of a path that models the actual url - blogs/get/12's action is /blogs/get/action.js. 

There would probably still be a need for action and view helper folders, but they'd be a lot shallower and smaller. 

Admittedly, this organizational scheme would require a lot of drilling to get to models and views. A symlink script to reference all models from a central folder might still be useful, but I think users/model.js is about as accessible as models/users.js. 

One added benefit of decomposing the controller file is that you end up with a lot fewer git merges, and its easier to multi-user edit within a single response group (users). I can edit the _get/action.js while someone else edits the _post/action.js, and the git trails never cross. 

Shared functions and other bits can be put in users/parent.js, an optional file that all subsequent actions inherit from. 

I think the seperation by type conciet that MVC has set forward implies that the views and models would be worked on by seperate teams, a pattern I've never seen played out in the real world.