The MVC vs PAC article linked to is in fact splitting hairs--the most popular PHP MVC frameworks out there discourage calling the model from within the view, so that should not be the defining factor in the differences between PAC and MVC, or even anywhere near the top of the list.

The pattern heavily utilized by MANY MVC frameworks out there is that the Model provides access to the data, the controller processes requests, pulls in and formulates model data for the view, and then renders the view. The view is "dumb" much like how it should ideally be in Drupal anyway. The only real PHP code in the view should be things like outputting variables, formatting dates, and looping over arrays to generate lists, tables, etc.

CakePHP and CodeIgniter, for example, are not PAC frameworks; they are MVC frameworks, and they don't work the way the PAC vs MVC article says they should. It's not about how strictly you adhere to the specifications of a certain methodology, but how clearly you define your own use of the chosen methodology and portray it in such a way that users can grasp it and get the most out of it.

Drupal does not clearly define how to develop with it "properly" using the PAC methodology. It exposes a few places where users can insert their own functionality without most people going any deeper than that and figuring out how they can relate best practices in PAC development to their Drupal work.

ANother of my biggest problems with Drupal is its lack of encapsulation. Not a day goes by when I don't have to create long, hard to read names for my functions because they're sharing the same space with all other functions in all other (foreign) modules--and we simply have to rely on the assumption that every other module and theme developer has adhered properly to drupal's naming standards and won't ever use a name that any other plugin's methods might want to use.

My other problem is with separation of concerns. A 'module' is most often not a single entity that performs a single task, but a bundle of functionality whose hooks are usually all just mashed into one .module file. Unless you're creating a new module for every small task you want to accomplish, the code gets quickly unruly and turns into speghetti code.

It's not that it's impossible to create nice, structured code with Drupal, it's that there is no clear standard way of doing it in Drupal. Now that PHP5 is a clear standard, enforcing proper OO patterns would be a great way of ensuring an organized, easy-to-maintain codebase and far greater modularity. With Drupal, it's hit or miss because it's so darn simple to create bad, unmaintainable code when writing themes and modules.

I'm fine with a PAC architecture, I just want Drupal to implement a more object-oriented approach so that modules become easier to standardize, easier to maintain, easier to read and understand, and safer for the global namespace. I'm tired of hearing about how certain parts of drupal 'mimic' objects and encapsulation, because that simply makes it muddier and harder to grasp. There's been a standard object model for years, and there's no reason anymore to work outside of that while still trying to achieve a similar result.

But that's just my two cents, and it comes from an on-and-off relationship with Drupal and other frameworks. Every time I return to Drupal, I'm amazed how many times I find myself doing things I wouldn't even consider in another framework because they just feel like bad practices.