Some people tend to get really annoyed by the tag line "next generation PHP framework". But I firmly believe that the concepts put forward in Cognifty will catch on to the PHP community at large in the future. Here is a breakdown of features that are not yet common in most PHP "frameworks", but should be common to all Web applications.
The mere existence of spam fighting Web services like Akismet prove that enough popular Web applications exist which lack any decent spam controls. Most people don't need to ship their e-mail to a 3rd party service and have successful results fighting spam with spam assassin and similar products.
Some PHP Web applications scan the GET or POST variables in 1 or 2 places in the code for keywords and erase or block offending input. Sometimes plugins like BadBehavior can be jammed into an existing project, but the result is kludgy at best, haphazard at worst.
In the next round of Web frameworks, customizable systems - much like BadBehavior - will be embedded into most major frameworks. The customizability will allow your PHP code to read a score of the input, much like spam assassin scores, and determine what to do with the Web request, instead of simply erasing the input, or stopping the request whole-hog.
Similar to a concept of "karma" on some message boards, an engine for community approval over every piece of content a user generates will be standard in the coming frameworks.
Some Web frameworks omit the concept of a "user" altogether, leaving it up to the application developer to re-invent the wheel over and over on every new project. Soon or later, framework makers will realize that all Web applications require the concept of a user to effectively combat spam.
Furthermore, as API usage continues to grow, the line between users and 'bots will blur, thus requiring some level of defined trust to be attached to user accounts. A trust rating can be used in conjunction with spam rules to increase the efficacy of determining actual spam content from good, "ham", content.
A lot of Web frameworks tout the "MVC" pattern, which was originally applied to a complex GUI widget and a complex data model. But a fully generated Web page consists of many disparate pieces of information that don't easily fit into one data model. The front controller pattern is also a great pattern for handling Web requests, but it results in too much duplicate code.
The next generation of Web frameworks will have a method of grouping similar controllers together under an umbrella of similar settings. Adding an extra layer on top of controllers will extrapolate duplicate code into a few settings files and help developers organize large applications into sets of sub-applications.
Code generation is poured into the PHP realm with the help of libraries like PBDO and Propel. Further spurred on by projects like CakePHP, code generation can seemingly speed up development when compared to starting from scratch. But code generation involves learning the tools to implement the code generation, and can only save significant typing if you're not using libraries coded for the task at hand. Code generation can speed up run-time execution. But, its usage must be traded off with managing a larger code base.
Next generation PHP frameworks will do away with code generation in favor of libraries with good default behaviors. This means that you only need to change behaviors that you don't want, thus, making the amount of typing proportional to the amount of changes that the developer needs to implement.