That's really too open-ended to answer. Plus the best frameworks come from solving a specific problem and generalizing, not trying to be an abstract general frameworky thing from day one. Pick a project, concentrate on writing good code with DRY (Don't Repeat Yourself) and you'll naturally be writing a framework that can actually do something.
To write a framework, you need to know what problems you need to solve. You get that from trying to write websites, not from trying to write frameworks. I strongly recommend against trying to cargo-cult a framework ("well, they have ORMs and MVC and dadadada, so I'll write an ORM and do MVC and dadadada because that's how it's done"), because you may get the letter right but you'll be missing the spirit. (Not that some very successful frameworks haven't suffered from exactly that.... no, I'm not talking about any of the really big hitters, but some of the mid-tier ones have this problem.)
I would start by not building a web 1.0 style framework. We are in the middle of a transition to richer browser based applications and server side, non-standard web technologies like PHP, ASP, JSP, Servlets that spit out HTML are being passed over for straight HTML, JavaScript, CSS and XHR calls to the server this is a good thing because it simplifies the stack significantly.
If I where to build a framework now, it would be a framework build on one of the JavaScript toolkits (at least pluggable so any of them could be integrated, If I had to chose one it would be Dojo or jQuery depending on what I was targeting), a REST library, a content based router and a security API. I would also consider bolting on a CMS that templated HTML and exported it to pure HTML on a web server. This is where the future of the web is heading to build another ASP.NET or PHP or Struts on Node.js will give your product a limited lifespan.
I'd love to understand this ideas better. Can you explain each of those components of your system? What is a "content based router"? The "security API"?
To write a framework, you need to know what problems you need to solve. You get that from trying to write websites, not from trying to write frameworks. I strongly recommend against trying to cargo-cult a framework ("well, they have ORMs and MVC and dadadada, so I'll write an ORM and do MVC and dadadada because that's how it's done"), because you may get the letter right but you'll be missing the spirit. (Not that some very successful frameworks haven't suffered from exactly that.... no, I'm not talking about any of the really big hitters, but some of the mid-tier ones have this problem.)