Quite a long time ago I started the discussion about the future of the profile as nodes solutions out there (link). There was a lot of input to the discussion and most people (including me) agreed on variante 2 "build upon a small base module". This means we build a small, well tested simple profile-as-node solution, which can be further extended by other modules. So I had started developing content profile and invited others to join in - but unfortunately no one did. Now after some discussion it looks like there will be a 6.x bio version - introducing the imho unnecessary duplicity again. As an affect code like views integartion, user register integration and so on has to be written twice - once for each solution. But in my opinion the worst is that further extension modules, which want to build extended functionality on top of "profile as nodes" can't support all solutions by building upon a single module - they would have to build support for each solution on its own. Don't mentioned that they can't rely on a unique API to do so. So what I'm going to do now? As content profile is already in place, I'll keep it as basic 6.x version of node profile - there won't be a node profile module for 6.x. However as content profile is simpler than node profile, it misses some features of it (user registration integration, user edit categories integration). As bio already has user register integration and probably will have it for 6.x too, I'm not sure if I'll "roll my own" as one can just use bio for that (together with content profile). This means, if you need functionality relying on bio, enable bio. If you need functionality relying on content profile, enable content profile. If you need both, enable both. So I'll do any further development related to this (like complex profiles consisting of several content types) on top of the content profile API - so everyone can install content profile and use it.