Is it just me or are this.mappings acting funny?

Question

Let me preface this: The following code is in the pseudo-constructor of my application.cfc (outside all functions) and this is the FIRST run of the application (so the application has not yet initialized)
With that being said, I wrote the following code:
<cfset this.mappings[ '/model' ] = expandPath( '/path/to/models/folder' ) />
To make sure it took, I dump it:
<cfdump var="#directoryExists( '/model' )#" />
And sure enough I get: YES.
Remove the dump and add the following code:
<cfset myConfig = new model.utils.Config() />
And CF errors out telling me it cannot find a Config.cfc.  Well, I verified.  In that 'models' folder, there is a 'utils' folder and a 'Config.cfc' in there.  If I instead change the line to read:
<cfset myConfig = new path.to.models.folder.utils.Config() />
Then it works fine.  So in essence, the mapping is not working.  I have an odd feeling that this is all due to the fact that I'm doing this in the pseudo constructor area, but if that's the natural place where you define this-scoped variables, I would think this is OK.  I know the application.cfc is LIKE a CFC, but in some ways different.
Well, if I create a this-scoped variable in some other CFC file, I can immediately reference the variable and value on the life after, even in that CFC's pseudo or in the INIT before I perform a <cfreturn this /> 
I'm trying to understand why the mapping is not working.  A problem I have is that the returntype attribute of my Config.cfc is 'model.utils.Config', and this errors out when I use the 'new path.to.models.folder.utils.Config()' method, understandably because they're different FQDNs.

Answer 1

I applaud Sean and his "Convention over Configuration" approach on FW/1.  And I know that FW/1 has been touted as a very simple and straight forward Framework.  There was a time a while back that I tried to learn it, found the documentation a bit lacking, and was told by its immediate community to "RTFM".  Problem was TFM wasn't making any sense to me.  When a manual does not talk in the lowest common denominator and assumes the reader has certain understandings that they currently don't, it makes for an even more frustrating experience.
But here's the thing.  I do know that "reinventing the wheel" is not the most time-effective approach.  I will admit there is something in me that is uncomfortable with using other frameworks simply on the merits that I feel it will not allow me to be as customizable in my solutions as a home-grown one.  Also, I will state that in my own attempt to make my own framework (which, to be honest with you, has been going very well), I have learned SO. FREAKING. MUCH.  Sure, I didn't learn it in the most optimal way, many times I had to back track and "refactor" code when my envisioning of the framework became more and more clear; but wow, it's one heck of a ride and a sense of accomplishment when you can get through those milestones (mostly under my own steam, but definitely not completely without the help of others like yourself who have been very helpful).
I keep repeating my mantra.  "A simple as possible, as complex as necessary."
There is a nagging voice in my head that says "These other developers don't reinvent the wheel.  You're wasting time by learning frameworks this way.  When employers want to hire, they're not going to ask if you have experience in an unpopular framework."  (good ol, self doubt, eh?)  But I think for my current situation, I'm not going to say "No" to other frameworks, I just feel I have to currently power through this custom one.
Besides, whether I use FW/1 or my own FW, my current issue is moreso about not understanding how I previously thought CF functioned.  That's something that needs to be understood despite my FW of choice.