Reasons

Why was CFlow developed? There are already so many other frameworks around. No one needs this!

Could be. And its probable that this framework will not be adopted by the ColdFusion masses like Fusebox or Mach-II. In the end, this is not important to me. I was not satisfied with the frameworks I looked at, for different reasons.

• For some frameworks the learning curve was too steep for me. I don't know if the learning curve for CFlow is steep for other people, but the concept feels very natural to me. I hope to you too.
• Probably related, many frameworks have all kinds of objects that are there to manage things. Maybe they are needed to keep the object model nice and tidy, or to put as much flexibility in the hands of the developer, but for something that handles requests, I thought I wouldn't need such a complicated object model. (I think I ended up with quite a few objects though.)
• Some frameworks depend on other frameworks, such as ColdSpring. ColdSpring is very cool, but for some reason I don't like it so much. Maybe it's too much of a black box, maybe it's too big a tool for the purpose, maybe I just don't understand it. Anyway, I don't want it as a dependency. Of course, if you are a ColdSpring fan, CFlow doesn't hold you back.
• Some frameworks have too many features that I don't need. I like it if something does what I want, not more. The same thing goes for ColdFusion itself btw, so many features I don't need. But that's a different story.
• For some frameworks, I don't like the code. Sometimes so many lines of code are executed for every request, just to gather all necessary parts, that it just doesn't smell good to me.
• Often I see that controllers decide which view to use. In my opinion, that's too much coupling. Yes, in MVC the controller knows about the view. But MVC is originally a client side pattern, it was adapted for the server side later. On the client side, you start with UI elements, then you attach controllers. In fact, the controller is a strategy, as in the strategy pattern (read the section about MVC in GoF), it sort of lives inside the UI element. On the server, it's the other way around. First you get a controller, and later on you render output. Often you don't exactly know which output. Sometimes I want HTML, sometimes JSON, for instance. If I have a method with a sizable chunk of code that is tightly coupled to the HTML view, I have a problem. The only solution that pops up is moving that chunk of code in another private method and call that from the spots where I need HTML or JSON. That would work, but it's far from elegant in my opinion. I think it's better to try to completely remove the coupling between the controller and the view, on the server side.

Probably the most important reason to develop CFlow was that the whole idea was very compelling to me, and it was fun to develop. That should be enough to develop anything, I suppose.