I think the problem we're sort of debating here is abstraction levels. The last time I looked at any code required to program a Windows Message Loop was maybe 1993 ... I might have spent one day messing with it and just wanted to throw up. Thus, I was familiar enough with it to recognize what a HUGE accomplishment it was that Delphi was able to totally hide it!
That said, it took me a while to get comfortable with Modal vs. Modeless forms and the quirks they have at their edges. Over the years, I've seen so much code where the authors of certain forms were NOT really aware of the differences, which is usually when the app's Architect mandated a specific calling sequence for creating and disposing of forms that was likely an attempt to impose some (misplaced) consistency everywhere in the app. This always leads to some strange contortions in certain places in the code.
I'm consistent enough in my own use that I pretty much don't worry about it. It's when I have to deal with code written by several different devs who themselves aren't consistent.
I've got other beefs about how forms are managed, or mis-managed, by most Delphi devs, but that's more of a religious debate that nobody ever wins. (It's what inspired my CodeRage 9 talk.)
Anyway, it seems reasonable that the normal abstraction levels that we're using to create and interact with forms should reflect a consistent implementation under the hood. I doubt 90% of Dephi programmers have ever seen what's involved in the Win Msg Loop, nor should they need to be aware of it. Except for the quirks that David points out. (Or why, although Forms are normal objects, nobody wants to create or use normal properties to move data in and out of them like every other type of object they'd do that for... but I digress.)