I have of course seen that, but it doesn't fill potential users with much hope when they see it. I'm sure it's lovely, but in the scope of the article it is just not solving the problem unframeworks set out to solve.

It has also failed to keep up with progress, for example: fDate is basically the same as the recent DateTime object in PHP, as are many other classes now.

Your comparison of fDate to DateTime is a good conversation starter. fDate was built precisely to provide such functionality as DateTime does, but it works in PHP 5.1. DateTime is only available in 5.1 if you explicitly enable it. fDate means you can use sane date handling on any version of PHP without worrying about what exact environment the code will be run on.

If you dig into Flourish for a bit, you'll find that Flourish is basically aimed at being a portable, secure base layer to build stuff on top of. It gives you a platform to work in PHP one layer above the PHP functions that are largely derived from C libraries. It includes stuff like UTF-8 string functions, input filtering, arbitrary precision math and whole bunch of other stuff that will work with any kind of (semi-popular) DB on any platform with any version of PHP 5.1+.

Because of this, it isn't going to use PSR-0, or namespaces, or other new language features in PHP 5.3+. However, due to the architecture, you can successfully use it with PHP 5.3 or 5.4 and use all of the new language features in your part of the code. However, when you need to actually send a standards-compliant email with an attachment including UTF-8 content and inline images in the HTML version, fEmail has your back. Oh, and it prevents email header injection along the way. :-)

What problems does it not solve that the unframework concept is supposed to solve? I'm a but curious on what I'm missing out on, as I continuously feel like it meets or exceeds all of my needs.

An unframework is designed to give you a set of classes that you can use to build your site. Sure, on that level it works but what about when you need more?

At some point you need to have more classes, and where do they come from? One team of developers cannot forever add in more and more classes, that would be ridiculous.

If they allow other people to add in other classes they have an ever expanding codebase. If they dont allow developers to add in other classes then you are back to the original problem: where do I find new classes that will work with my code.

By using a package management system you distribute the workload to people who need a class, and so make it. People who have a vested interest (client project, some web service they are making, whatever) are responsible for working on a set of classes that really benefit them, like a payment library that works with Recurly, Spreedly, whatever. That should be made buy one developer, and a second developer could add in a new driver - instead of building the whole damn thing from scratch.

That is the approach package managers take, and they are much more useful than a one-man-army trying to build all the libraries.

Again if Flourish meets your requirements then great, but it certainly doesn't meet all potential requirements of the whole PHP community, package managers can with the "use whats there, build what isn't" approach.