[eluser]BrianDHall[/eluser]
1- PHP4 - what does it hurt to leave CI as it is in this regard? I don't understand how removing php4 compatibility helps anything. Most extensions and external libraries for CI are available only under php5 anyway, so I just don't see the point. Honestly, why?
2- UTF-8 support - great! This I think would be of interest in general, but be aware that Ellison has already stating they'll be doing this in the next major release anyway, so any fork you do only be duplicating their effort and making initial utf8 support available sooner. Assuming you release something significant enough before they do, and there isn't exactly a way to do "utf8++" - once you have it, its done.
Why not just release details or a package to make the current CI utf8 compatible?
3- Libraries: everything you mention is something that can be done in CI as it is, without modification. There are numerous auth libraries available, and still isn't one I think is a slam-dunk.
4- CMS - there is presently Ionize being heavily developed, PyroCMS, ExpressionEngine for a commercial solution, and countless other lightly used CMS projects.
You state that you want to make a fork to make your own CMS, but why do you need to spend any time on forking CI when you can just focus on making the CMS? In its present state I don't see that it's stopped anyone from making a CMS as it is.
It just seems like there needs to be some good, big reasons to even touch a core CI file, much less attempt a fork. So far you haven't given any, so I just don't get it.
All the libraries you mention could be used in CI as it is, like Google Analytics, Google Maps, Google anything, facebook, twitter, myspace, search, modular cms, backend-only cms, ORM extensions...
