The importance of getting terminology correct
Terminology
Once again I found myself explaining to someone that the "MVC" architecture they were showcasing didn't follow the accepted definition so isn't technically MVC at all and doesn't offer the advantages that it's supposed to. The problem is that the incorrect definition--that's incorrect insofar as the wikipedia entry, academic references and professional sources have an accepted definition and this isn't it--is quite widespread among certain groups. Most notably PHP developers.
If a small minority are using one definition and everyone else is using another it doesn't cause issue until someone from one group tries to talk to someone from the other. If everyone around you is calling a "cat" a "dog" then everyone will know what you mean when you say "dog". However, as soon as you try to communicate with someone who understands and only knows the accepted definition confusion will ensue on both sides.
Further to this, if someone who knows neither definition attempts to look for information they will be presented with both definitions and this will lead to confusion. In this particular instance, there are a large number of people teaching the wrong definition. And calling it "wrong" is accurate because the original definition was coined, documented, published academically and widely accepted long before the misinterpreted variant began to appear. This causes problems because the original architecture has almost been lost among this group. And, in my opinion the original architecture which was developed by incredibly clever academics who thought very carefully about what they were trying to achieve is better than the misinterpreted approach which was created accidentally by people trying to apply the original architecture without fully understanding it.
Confusion
The problem this has created is that any time I (or a minority of others) attempt to explain what MVC actually is, we end up in an often hostile argument about definitions and terminology. This detracts from the real debate: "Terminology aside, which is the better architecture?". However, any discussion is rarely allowed to get that far because PHP developers in general have a very fixed view that "MVC is the answer" they put it on a godlike pedestal and any other architecture is worse, simply because it's not MVC. What makes this amusing is that their definition of MVC isn't MVC either and lacks a lot of the benefits MVC actually offers. This mentality is almost certainly due to the number of "MVC" frameworks (none of which is MVC, however), that utilise this misinterpreted definition. It's reached the point where suggesting the use of any other architecture will raise eyebrows from even the most seasoned developers for the simple reason that it's not what people are used to and it goes against their preconceptions and everything they have learnt to date about the architecture.
Because of this, any attempted discussion around architectures involves a hell of a lot of resistance and a large amount of clarification of the various terms. If people hadn't applied these terms to things that didn't match the accepted definition to begin with then we wouldn't be in the position now where people get confused because there are multiple similar definitions for any particular term and it's impossible to have a sensible discussion on the topic because everyone is reading from a different hymn sheet.
This situation is unavoidable to a certain extent, everyone will inevitably interpret the original definition slightly differently. However, it should have been better managed than this. The blame almost certainly falls at the hands of framework authors and bloggers who began teaching definitions which fell well outside the accepted definitions in the first place. You'll notice that none of these early bloggers, tutorial writers and framework authors supply references. Try to find any references or even reasoning behind design decisions on the CakePHP or CodeIgniter documentation on MVC. You won't! They just incorrectly say "This is MVC". This is why references are so important in academia, even totally new concepts need to build on some existing ones. If the early bloggers and framework authors hadn't incorrectly labelled their architectures with the already widely used and accepted "MVC" tag but had chosen something new we would not be in this position. The problem is, these pioneers were trying to implement MVC but clearly didn't have a proper grasp of the concepts behind it. Because of this, they called it MVC because it's what they were striving for. This is a good goal but they missed it and accidentally spawned a decade's worth of misunderstanding and dozens of copy-cat frameworks that use this skewed and incorrectly labelled architecture. None of which that supplies any reason for choosing the architecture in the first place.
Conclusion
This hurts the entire community. It makes it difficult for experienced PHP programmers to understand concepts from elsewhere in the programming world and it makes it very hard for developers who are trying to learn about advanced topics such as architectures to learn because they have contradictory information to contend with. How are they supposed to know which to follow? And it makes it difficult for anyone who tries to implement a true MVC architecture because they will experience a lot of criticism from their peers.
I feel most sorry for people who have taken the time to study and learn who are only trying to improve themselves who are left in a situation where they've studied and learnt only to discover that what they've learnt wasn't entirely accurate.
Where do we go from here? I honestly don't know. We have two separate architectures using the same name and thoroughly causing confusion. My own approach is education: Teach people the difference between the two patterns and discuss the pros/cons of them rather than just how-to articles. Although understandably most people just want to get a job done and don't care about how it works. But, framework authors, bloggers and enthusiasts should all be more open to exploring the differences and choosing the right tool for the job even if it does hurt their ego a little in the process.