2.24 is outdated; please try 2.26.

Your step 3 is rather strange; normally one doesn't set gconf settings this way. What's the output of this command:

gconftool-2 -R /apps/gnome-terminal/keybindings

?

If the keybindings editor shows no shortcut assigned for these actions, that means the settings could not be read from gconf.

Debian doesn't have 2.26 yet, and I don't want to install GNOME apps outside the packaging system.

I originally set the settings in ~/.gconf.shared via gconftool-2; it just seemed easier for the purposes of reproducing the problem to give the relevant contents of the file. gconftool-2 shows the expected values for new_tab, next_tab, and prev_tab:

$ gconftool-2 -R /apps/gnome-terminal/keybindings | sort
 close_tab = <Ctrl><Shift>w
 close_window = <Ctrl><Shift>q
 copy = <Ctrl><Shift>c
 detach_tab = disabled
 full_screen = F11
 help = disabled
 move_tab_left = <Ctrl><Shift>Page_Up
 move_tab_right = <Ctrl><Shift>Page_Down
 new_profile = (no value set)
 new_tab = <Control><Alt>n
 new_window = <Ctrl><Shift>n
 next_tab = <Alt>Right
 paste = <Ctrl><Shift>v
 prev_tab = <Alt>Left
 reset = (no value set)
 reset_and_clear = (no value set)
 set_terminal_title = (no value set)
 switch_to_tab_1 = <Alt>1
 switch_to_tab_10 = (no value set)
 switch_to_tab_11 = (no value set)
 switch_to_tab_12 = (no value set)
 switch_to_tab_2 = <Alt>2
 switch_to_tab_3 = <Alt>3
 switch_to_tab_4 = <Alt>4
 switch_to_tab_5 = <Alt>5
 switch_to_tab_6 = <Alt>6
 switch_to_tab_7 = <Alt>7
 switch_to_tab_8 = <Alt>8
 switch_to_tab_9 = <Alt>9
 toggle_menubar = (no value set)
 zoom_in = <Ctrl>plus
 zoom_normal = <Ctrl>0
 zoom_out = <Ctrl>minus

Please try this again once you've upgraded to gnome 2.26.x's versions of vte, gnome-terminal and gconf, and re-open the bug if it's still reproducible.

(In reply to comment #3)
> Please try this again once you've upgraded to gnome 2.26.x's versions of vte,
> gnome-terminal and gconf, and re-open the bug if it's still reproducible.

I just upgraded to gnome-terminal from 2.26 (Debian package 2.26.2-1).  I already had 2.26 versions of the other bits.

I can still reproduce this problem.  The keyboard shortcuts for new tab, next tab, and previous tab do not work after upgrading.  Yet the keyboard shortcuts dialog shows each of those keyboard shortcuts set to the key I configured via gconf, grayed out and disabled because I've effectively set them as mandatory settings.

Reopening the bug.

Hmm. Please re-build the g-t package configuring it with --enable-debug, then run g-t from an xterm like this:

GNOME_TERMINAL_DEBUG=accels gnome-terminal --disable-factory

and attach the debug output that this should produce.

(In reply to comment #5)
> Hmm. Please re-build the g-t package configuring it with --enable-debug, then
> run g-t from an xterm like this:
> 
> GNOME_TERMINAL_DEBUG=accels gnome-terminal --disable-factory
> 
> and attach the debug output that this should produce.

Done.  Attaching...

Created attachment 136682 [details]
GNOME_TERMINAL_DEBUG=accels gnome-terminal --disable-factory > gnome-terminal-debug-accels 2>&1

Ping?  Any more information I can provide to help with this bug?

The debug output is exactly as expected, no difference what I get hereto (except as expected, where using different key combinations, of course). 
And changing the accels to ones from comment 0 works here.

So I have no idea why it wouldn't work on your system.

Do the steps I described to reproduce the problem starting from a new user account work for you?

I just tried a few experiments with 2.26, and I managed to find another useful detail.  If I remove the mandatory entries for keybindings from my .gconf.shared, I can then set the keybindings via gnome-terminal's keybindings dialog, and those keybindings work.  However, if I then put the mandatory entries back, the keybindings no longer work, even though "gconftool-2 -R /apps/gnome-terminal" gives *exactly* the same output either way.  It seems likely that gnome-terminal has some problem with mandatory entries for keybindings.

Also, on a hopefully unrelated note: while reviewing the code in src/terminal-accels.c, I noticed this interesting bug:

static const char *
key_from_gconf_key (const char *gconf_key)
{
  const char *last_slash = strrchr (gconf_key, '/');
  if (last_slash)
    return last_slash++;
  return NULL;
}

last_slash++ doesn't do anything useful here.  Perhaps you wanted last_slash + 1?

OK, I managed to track down the problem to this code in terminal-accels.c, in the keys_change_notify function:

  gconf_writable = gconf_entry_get_is_writable (entry);
  if (gconf_writable != key_entry->gconf_writable)
    {
      if (gconf_writable)
        gtk_accel_map_unlock_path (key_entry->accel_path);
      else
        gtk_accel_map_lock_path (key_entry->accel_path);
    }
  key_entry->gconf_writable = gconf_writable;

Here, if gconf_entry_get_is_writable returns false, keys_change_notify calls gtk_accel_map_lock_path.  keys_change_notify then later calls gtk_accel_map_change_entry to set the keybinding.  However, gtk_accel_map_change_entry will do nothing with the path locked.

To test this, I put an #if 0 block around the if shown above, preventing the calls to gtk_accel_map_lock_path.  The resulting gnome-terminal handled my mandatory keybindings just fine.

Clarifying summary based on this new information.

Should be fixed on git master.

(In reply to comment #15)
> Should be fixed on git master.

Awesome!  Thanks for the fix.

(For later cross-reference purposes: looks like the fix occurred in git commit b43fcdfd20c6eb4f972333080a435ba8567cc6fa)