Resizable windows, zoom buttons, & palettes - a GUI design question

I've got a GUI design question that has been bothering me.

It may be worthwhile checking out the HIG (http://bit.ly/8TPr0u) on title bars and panels. There are several good images there on the acceptable configurations of the title bar buttons. But, the particular statement that I would like to focus on is:

    Include the zoom button if the window can be adjusted in size.
    
So, my first question is, under what circumstances would one not include the zoom button if the window can be adjusted in size by the user? Are there any acceptable circumstances? (This is only partically rhetorical, because there may be one below. I assume that from a purely academic perspective, there are no acceptable circumstances in a typical Mac application - immersive games, for example, might be excluded.)

With a few notable exceptions, every palette I see is not resizable and therefore has no need for a zoom button. For those palettes that are resizable, with a few notable exceptions, they all have the zoom button.

Now, with that introduction, my specific cases involves a palette with a set of tool buttons. The issue is this:

    I want the palette to be resizable so the user can
    orient it nearly any way they wish - i.e. 1xn, nx1 or
    ixj where n is the number of tools on the palette. A
    visual representation of these three cases would be:
    
    1xn -   xxxxxxxx
    nx1 -   x
            x
            x
            x
            x
            x
            x
            x
            
    ixj -   xxxx
            xxxx
            
            or
            
            xx
            xx
            xx
            xx
            
            or ...
            
The design problem rears its ugly head in the nx1 case. In this situation, the palette is not wide enough for the zoom button to appear because the width of the buttons controls the width of the palette. Now, the width of the buttons could be increased, but maximizing screen space for the content is critical and the buttons are already as wide as is acceptable.

So, what do you do?

One solution would be to simply hide the zoom button in every case, but this would be a violation of the HIG.

Another solution would be to hide the zoom button in the nx1 case, but this again, would be a violation of the HIG, but, perhaps, a less egregious one.

A third solution would be to disallow the nx1 case, but this reduces the visible area for the content and is not an option.

A fourth solution would be to make the palette just wide enough so the zoom button can appear, but not two columns of buttons. But, this looks a little odd and works a bit strangely in actual practice.

Are there more options?

There seem to be two mutially exclusive options here. Either follow the HIG and make sure the zoom button is available or hide the zoom button in at least the nx1 case so the user desire to maximize the visable area for the content is met.

So, who wins? HIG or the User? Ok, well, I can (grudgingly ;-) accept the user wins because they are the one with the checkbook. But, still, I am drawn to the general philosophy on the Mac that all applications should look and work the same and therefore the zoom button should be there. The user benefits from this philosophy by not being forced to learn unnecessary quirks of how a particular application works. So, in some sense, if the HIG wins, so does the user, even if the user doesn't recognize the immediate benefit.

So, what I am hoping for is that some kind of move sideways is possible. Perhaps there is a different design here that I have not considered. Now, it may not be possible to answer this question because the alternative design might be dependent on the specific application, but if you have run into a similar situation, I would be curious how it was resolved...?

Thoughts? Comments? Questions?