My first question would be "why are you building a framework?"
Surely there has to be something sub-optimal, missing, broken, or otherwise defective in the existing frameworks even if that something is just that they don't look at the world the way you do (and there is nothing wrong with building a framework to solve a problem domain "your way"--that can lead to a lot of illumination in how to approach problems both for the authors and the users of the framework).
Assuming there is an answer to that question (if there isn't, there is no reason to build the framework at all), then the answer should guide your architecture decisions. There is a lot of wrong-headedness in terms of how design patterns are viewed. They are no panacea. They do not solve problems. They are a way for software engineers to discuss common implementation strategies--but the implementation strategy is derived from what is being implemented.
Perhaps a good way to make this more clear would be to break down some common design patterns.
For an MVC framework, the guiding pain point is that you want a clear division of code--a good separation of concerns. Maintainability and refactorability. For an ActiveRecord ORM, the idea would be to abstract away as much of the database dealings as possible, allowing the users to think in purely object-oriented terms. And so on.