...

I have never heard before about "the utility window type hint".

It is defined in the Free Desktop window manager specification. IIRC the KDE window manager claims to adhere to that spec:

http://www.freedesktop.org/Standards/wm-spec

It may be aware of it internally, but there are no configuration controls available to the user. Most importantly, I cannot set utility windows to stay on top within their app or be hidden on the taskbar. The freedesktop specification is bright and wonderful, but looks like we (Inkscape) will have to use transients until that specification is better supported in WMs. (Even though transients have their problems, too.)

...

For example, if you add a third option, "transient", to the "window type hints" list in Preferences and make that the default (both for toolbox and for docks), I think the default Gimp will behave in a more expected way for the majority of new users (while remaining usable for those who prefer another behavior.)

Transient implies a parent and there's no parent window the toolbox or docks coule be transient for.

Wrong. First of all, when a dock "follows active image", I see no reason why the active image cannot be considered its parent. And when you switch images, re-transientizing all docks to the new active document window actually works pretty well. Test the Inkscape CVS to see what I'm speaking about.

And second, even when a dock does not follow active image, it is logical to consider all open document windows a "collective parent" for all docks, so that docks and toolbox stay on top of the topmost document. This is what we're doing in Inkscape, and the feedback has been very positive so far. Which is understandable, given that our approach is a good approximation of what Windows/Mac users come to expect. (And if you feel your document is cluttered with dialogs, we'll soon have a global key that toggles all dialogs and toolbars off and on.)

Which brings us to the point, do you want to really win user share from commercialware? After all, in many cases what is required is just change a few defaults, and I don't see any reason not to do that because it won't affect power users who have their preferences set differently anyway.

...

I noticed that menu option and it was indeed on, but it did not do anything for me. As I now see, there's one more thing I had to do: "Activate the focused image" in Preferences must be on. Please make that setting on by default, too.

We discussed this recently on the mailing-list. And the outcome so far was that the default should be off since it is almost possible to work with this setting with a window manager that does focus-follows-mouse.

First, I may be missing something but I have just tested "Activate the focused image" with "Focus follows mouse" in KDE, and it's very convenient. I see no problems with taht so far.

Second, users coming from Windows or Mac will never have "focus follows mouse" set. This is counterintuitive for them. Those who use this setting are more likely to be power users, and power users will be able to configure this in Gimp as they see fit.

Please note that all it changes is the behaviour when you click the window decorations. There are other ways to activate an image.

Not only click. Many use alt-tab as the primary way to switch windows.

...

Sure, but zoom keys are the first any user will try to use, why not make them more convenient by default?

It's a convenient setting for most users and it is a logical binding as well. Surely a lot better than '='.

Have you done usability tests with newbies? Do you think they will be relieved to know that zoom out is a no-shift key while zoom in needs a shift? Why argue when we can just test?