The initial window has no initial picture to define it's size. I suspect that is why a thin version appears. If I touch the grow region, it becomes accessible to dragging for a resize.
You observe large images having incorrect defaultFrame. I try to formulate a clear working or "not working" hypothesis. Since NSWindow allegedly declares as implemented by the delegates developed method, some code in NSWindow supplying defaultFrame to our procedure has a bug. It seems to me you found a bug in the cocoa frameworks.
I didn't know where to get images larger than my screen to get any amplification on your observation of defaultFrame's errant behavior, however, I got some other odd (to my imperfect understanding) behavior.
I used the grow region and window titlebar drag region to make a stdFrame go bigger than screen and found no event excited the adjustment of origen and extent. I don't know on what event the redefinition of stdFrame is fired.
I am going to try adding the procedure to the last columns version that had an initial picture and Michele's drag and drop augmentation to see what I fall into serendipitously.
Help viewer NSWindow ask got me "Using window notifications and delegate methods" sounded like a Feb.20,2002 advertisement. Documentation of extremely complicated things must start out that way to give writers time to write and good readers who wish to participate with that documentation in a community must forgive this.
So I might physically hop around my developer cd's to see if there was a later installment and, multithreading my search strategy in my own brain's software, investigate what an indexed sherlock or marshmallow librarian can find me better than help viewer in the html doc's. That way I concurrently catch the possibility that later docs were already there and are not to be found on a newer cd. I call this a shallow search, not assuming that a solution is to be found in any one particular venue but executive timeslicing my efforts so as to insure "halting doesn't become a problem".