Ah, writing frameworks - the most noble of pastimes for experienced developers!
I've written my fair share of frameworks over the course of my career in software development: workflow, integration, content management, validation, data-binding, remoting. And with the wisdom of hindsight I think I regret having visited each of them upon the rest of the development team!
These frameworks all served a purpose (apart from scratching my framework-writing itch). They bridged a gap between the technologies we were using and the requirements being implemented, thereby making these implementation tasks easier.
However, these requirements weren't particularly unusual and the technologies chosen certainly weren't. So it seems unlikely that these frameworks were fulfilling some new purpose that couldn't be met by an existing piece of software.
These days if I find myself writing a framework I appreciate a bit of introspection or criticism to keep me honest.
Many home-grown frameworks (my own included) are backed up by some strong criticism of the alternatives. Much of this comes from ignorance of those alternatives or a belief that yours won't exhibit the same, or indeed any, deficiencies.
As a general rule I'd say that you really don't want to own your own framework code. At the very least you can opt to defer taking ownership by selecting an open source alternative or using professional services support for a commercial offering. This makes speculative concerns about third-party frameworks less, well, concerning.
I'm surprised how many development teams rely on open source software yet prefer to hack their way around problems (with vitriolic commentary) rather than contribute a defect report, let alone a fix! It's not just polite, it's less likely to result in regression defects.
If you are writing your own framework then it pays to be clear where it's going to recoup the cost of ownership. Creating a generic solution is unlikely to be the most efficient way of meeting your requirements and moves the framework from the problem domain into the abstract, making it less intuitive to those most likely to be working with it.
Keep things no less specific than necessary, targetting your problem domain, environments and development process. Abstract where it provides clarity rather than as a precursor to world domination.
Although our architectural decisions are supposed to be costly to change, successful designs often reduce that cost, making other choices less important.
Rolling your own framework is not an ideal design decision and is simply incumbent due to a lack of suitable alternatives. The veracity of this statement should be checked from time to time as it will give you the chance to draught someone else's development effort.
It's not necessarily safe to assume that over time your framework will become better. It will probably become bigger, but since it's likely of lower quality than a third-party alternative its benefits may become outweighed by its ongoing maintenance and training costs. Improvements in the "competition" will also mean you may have to run just to stand still.
If you are intent on rolling your own framework then don't manufacture differences just to set your solution apart: they'll simply make it harder to migrate to other frameworks should the need arise.