It was done this way intentionally for CUA compliance.  If you prefer to change it, you can just set the toggled_maximized keybinding to whatever you prefer and disable the maximize and unmaximize keybindings.

What is CUA ? 
IMO, the "toggle maximization state" vs. "maximize" + "unmaximize" is a bit baroque, and I wouldn't expect a newbie (or even a power user who is not proficient with GNOME) to understand that bit. But whatever - I don't mind that much as I don't use the shortcuts for that, its just seemed to me like a poor choice.

Common User Access.  Some IBM standard from like the 80s or so widely adopted so that keybindings are similar between operating systems/desktop environments.  Anyway, if you want us to go against it, you'd need to file a bug against the HIG first; see http://developer.gnome.org/projects/gup/hig/2.0/input-keyboard.html#window-manager-navigation

IMHO: CUA or no CUA, I agree with Oded and have many times mistakenly pressed <Alt>F10 because I thought it would restore the window. Learning two keybindings is harder and counter-intuitive because both double-clicking on the titlebar toggles and clicking on the un/maximize icon. 
But if changing the maximize and unmaximize keybindings isn't possible due to CUA then I think it would instead be nice if the toggle_maximized keybinding was set to a keybinding by default. Then the behaviour would atleast be consistent across different installations and you wouldn't have to resort to gconf hackery to get the functionality.
Even nicer if the toggle_maximized keybinding could show up in the window menu because then it would be discoverable by non-power users.

I don't see anything in the HIG precluding metacity from using ALT-F10 to both maximize and restore at the same time, or ALT-F5, or both. That list is only as specified to prevent from other applications from overriding keyboard shortcuts used by the window manager.

I'm not familiar with the CUA, but from your description I would think that "expanding" on it so that the shortcut for "maximize" when hit again would restore (and vice-versa) would not be a violation.

If you can get mpt, calum, and bryan to make the usability declaration that something should be changed here and they specify the exact change, then I'll accept patches for it (please reopen in that case).  Otherwise, I'll leave it as is.  ;-)

Ok. Sorry for the bug spam I'm generating (I'm new to GNOME but would really like to help), but could you please give me some hints as to how do I get in contact with mpt, calum and/or bryan about this (and other issues) ?

They're on the usability-maint@gnome.bugs alias, so they should have received a copy of the last two updates of this bug (plus the one I'm about to make).  You can also find them at times on irc (irc.gnome.org).  I was referring to them by their irc nicknames, except that I made a mistake in the case of bryan (whose irc nick is clarkbw).  Anyway, their real names are
  mpt     - Matthew Thomas
  calum   - Calum Benson
  clarkbw - Bryan Clark
You can also probably track them down by googling (on e.g. 'mpt gnome' or other variations).  I'd suggest contacting calum first, as he has been more involved with metacity and keybindings from the beginning, then mpt as he's more likely to be available than clarkbw.

FWIW, the relevant CUA guidelines are here:
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F29AL000/2.2.106?SHELF=CEESL002&DT=19921204095534

("Unmaximize" is called "Restore" there, as it is on Windows).

I can't think of any specific objection to Alt+F10 working in addition to Alt+F5, when a window is maximized-- in fact, this is exactly what CDE does, so our CDE->GNOME switchers would probably thank us for it :)

Then, for consistency, should Alt+F5 re-maximize if pressed again?

Hmm, CDE doesn't do that, but there's a slightly different model happening there-- CDE minimizes windows to the desktop, from where you can either press Alt+F5 to restore, or Alt+F10 to maximize.  So, Alt+F5 /always/ means Restore in CDE, and Alt+F10 always means "toggle between restored and maximized state" (although it's only ever shown as "Maximize" on the menus, and is disabled when the window is maximized even though it does something, which is all a bit weird).

However, were the window list's keyboard navigation ever to be augmented so that you could focus individual window buttons (by pressing left/right arrows once the gripper was focused), we'd then effectively be in the same position as CDE.

If we think that's ever likely to happen, we probably don't want Alt+F5 to toggle; it should always mean "Restore".

If it's never going to happen, we're looking at a situation where we only really need one command, for which we might want to define two shortcuts for historic compatability (especially if bug 338805 ever comes to fruition).  And if that were to happen, we might want to move away from the notion of one of those states being 'maximized' anyway, and just toggle between two known states like the Mac does.  That's a whole different discussion though :)

I guess I'm saying "I don't really know", but I'd agree that, the way things are today, having Alt+F5 toggle as well would probably be consistent and harmless... but that may change if either of those other two things happen.

Calum's assesment sounds fair to me.  Hard to say how this will work if the changes in question take effect, however it's probably best to take the harmless and consistent approach for now; crossing the next bridge as we come to it.

Okay, next question:  Sounds like the current suggestion is to make Alt+F10 become the default binding for toggle_maximize (which is currently unbound by default) and make maximize become unbound by default.  Now, do we want to change the titlebar-right-click menu or the tasklist-right-click-menu (by s/maximize/toggle maximize/ or similar)?

I think it should stay as it is now - maximize or unmaximize depending on the state (although I personally would have preferred if it said "restore" instead of "unmaximize", which is a bit techy) - but also show the shortcut button for "toggle maximize" in both states - currently it doesn't show the shortcut if you assigned "toggle maximize" but not maximize or unmaximize shortcuts.

I think the logic should be sometehing like:
- are we in maximized state ? if "unmaximize" shortcut enabled - show "unmaximize <unmaximize shortcut>". if "toggle" shortcut enabled - show "unmaximize <toggle shortcut>". otherwise show just "unmaximize".
- same thing for not-maximized state.

BTW - is the change agreed above going to get into GNOME 2.18 ? Because in 2.17.2 that I'm using now it isn't implemented.

*** Bug 433343 has been marked as a duplicate of this bug. ***

Hi guys, sorry for the bug spam but what is the status for this 2.5 years old report? 
(especially considering that on 2006 it appeared that this usability issue is close to being fixed)

Okay, so what do we have to do here?

1) Change the binding for "maximize" to unbound.
2) Change the binding for "toggle maximize" to the previous binding for "maximize".
3) Rename "unmaximize" to "restore".
4) Make the right-click menu display the toggle keybinding if it's bound, with an appropriate name; otherwise display maximize, and unmaximize (this seems a bit over-complicated, and I'd rather just display the toggle keybinding with an appropriate name)

Right?

(1) & (2): Sounds about right. 

(3) & (4): Naming the actions is just a pet grieve of mine - it can be very simple. I just think that "unmaximize" sounds ungainly (and Mozilla's spell checker hates it ;-) )

Okay, I've done 1, 2 and 3, which were easy. :)

http://svn.gnome.org/viewvc/metacity?rev=4064&view=rev