Thanks for asking these questions because they're ones I hope I addressed in passing but also, I've been working on this in some form or fashion for so long, I take for granted that the abstract language I use to describe some of Nvigorate's qualities don't really help new people get any feel for what Nvigorate is/will become.
I don't want to tear down the efforts others are putting into their framework, but let me just say that I've had several of the more popular projects recommended to me by people who heard I was working on a framework that did X. There is something to be said for not re-inventing the wheel for no reason. Unfortunately, I have yet to find a framework that I personally feel is up to snuff, but all of them have so much code in place already that it didn't feel appropriate for me to stick my big nose in and start telling them what needed to change. So instead of naming open source projects, I'll focus on aspects of those frameworks that I felt make them inferior.
- Many frameworks I've seen are extremely limited in what you can do with them. They are designed to force you into developing according to the architecture of the framework itself. While that may be fine to do internally at a large company who writes their own software, that's not a practical approach to take when making a general purpose framework for others to use.
- Most of the frameworks appear to have been designed for a very limited scope. I've often found that some of them will only work under very controlled circumstances. For example: Class Thingy in their framework might say it's a general purpose database interface class, but as it turns out, it's really only meant to be used by one of their other classes, so your chances of trying to adapt the database access portion for customized purposes are slim to none.
- One or two I've seen lean very heavily on some technology or fad. The library revolves around some mindset so much so that it almost feels like the project was done as a class exercise to reinforce a newly taught principle. While that may work great for canned, small scale applications, it generally won't meet the needs of your average enterprise-sized application or system.
Nvigorate takes on more of a foundational class library approach than does any other project I've had time to really analyze to date. The framework is more general purpose in that it provides common interfaces, utilities, abstract factories and functional singletons. While it will do things like provide a very easy-to-use, yet versatile database interface class, it will also offer some more advanced functionality like data binding and ORM. But the differentiating factor in places where Nvigorate and framework X fill similar roles, the focus of Nvigorate is to help the developer build a best-class data binding and/or ORM solution rather than providing them with a limited and canned solution which forces them to design and develop against someone else's design.
I intend to address this more as time allows. Right now, I'm trying to get the first little bit of code done so I can post it and let people have a look. So much to do, so little time :)