In auto-split ledger mode (and possibly elsewhere):

Expected behavior:
  - Select a split transaction other than the last one in the register.
  - Edit the blank split.
  - Use tab to exit the (edited) blank split.
  - The cursor moves to the new blank split.

Erroneous behavior:
  - Select the blank transaction at the end of the register.
  - Edit the blank split.
  - Use tab to exit the (edited) blank split.
  - The cursor moves to the transaction split, instead of the new blank split.

Source:
  I had a terrible time trying to route this one out.  I finally resorted to stepping through the code in gdb in two different versions (2.2.2 and 1.8.11, which doesn't exhibit the problem) simultaneously, looking for differences.  The turning point was the call to gnc_split_register_find_split() on line 352 in gnc_split_register_move_cursor().  The old (working) version returns true, setting new_virt_loc to the location for the new blank split.  The current (malfunctioning) version returns false, setting new_virt_loc to the current_cursor_loc in reg->table (which is the Transaction split).

As it turns out, gnc_split_register_find_split() was modified by r14345 to fix Bug #343798.  (Chris even mentions in his revision comment that the change might do strange things to cursor motion.)  When I undid the change (removing the "&& s" criterion on line 228), the behavior of the two cases above matched (tabbing off the end of the edited blank split put the cursor on the new blank split).

Now, since the change was made to fix another bug, I doubt the solution is simply to reverse r14345.  Unfortunately, my understanding of the register is just about nil, so I can't suggest a proper fix.

Ideas?