Number 5 is right where I'm at right now. I'm still really new and have spent my time learning Ruby and Ruby on Rails. I've recently embarked down the Erlang path. The frameworks aren't nearly as developed as Rails and I've realized I have no idea what the hell REALLY happens on the server side. My current goal is to write a server and my own framework. I have no illusion that either will ever be used for production. But I know I'll never get to where I want to be as a programmer if I don't understand what's going on back there.
By the way, nice to see a post from you. It seems like it's been awhile.
I'm a little bit further on that point and I think you should slow down a bit.
(All that follows is my humble opinion, apply grain of salt and critique as needed)
Writing a framework for the first time is hard. You said you don't really know what happens server-side and this may get in your way. A framework is often designed to address specific problems/needs in a specific context.
These problems/needs don't have to be shared by anyone else, it could just be you thinking "It's hard to build RESTful urls, I should build something to do it for me" and have a CLI util or a script handler that would register them for you in your app server. And some can be everyday problems: "F*ckin' databases, how do they work?"[1].
However, you need to know these problems to address them. Which is a part of my long-term feud with frameworks: "If you always use a framework, you will never have (too much) problems and will never learn how to solve them" (writing my own active-record-like ORM for node.js is a lot of fun actually).
Which is why my advice to you is: Don't write a framework.
Instead, write an app, get stuck a lot of times and find a way. Identify your problems. Then write a different app. This time, look at what you are doing the same way, what problems you are solving another way and what you'd like your framework to automate. There, for this second app, you can start writing your framework because you'll have a better idea of what you need to address.
You don't really need to make a framework that caters to everyone's needs, but one that caters to your needs and expand from there.
Next (optional) step is rewriting the first app with the second app's framework and iterate new functionalities.
I solved this problem by using Sinatra rather than Rails. For most things you will build as a novice coder, Sinatra will do what you need and get out of your way.
When you start building bigger stuff, and your routes and controllers start looking crufty and ugly, and you start wishing you had more tools to keep everything organized, then pick up Rails.
I suppose you could try to hack together your own framework to give you a sense of what's involved. In Ruby this is done with Rack, it handles the HTTP requests and you can focus on the mid-level framework-y stuff. But seriously, Sinatra's what you'd eventually come up with, and it's already out there, so why not use it?
By the way, nice to see a post from you. It seems like it's been awhile.