Version details: 1.8.11
Distribution/Version: Slackware 10.0

I don't have the auto-split style of register selected, but I don't think it
alters this behaviour.

1. Open a register (Eg. Assets:checking)
2. Enter a transaction description which will activate quick-fill.  At this
point, I click Split in the tool bar to show the splits. (Mine shows the split
anchoring the transaction to this register as the last row.)
3. Tab through the splits until you get to the split for Assets:Checking.
4. In the split for Assets:Checking, change the account to something else (Eg.
Expenses:Groceries)
5. Tab over to the "deposit" column.  Enter an amount.  Tab over to the
"withdrawal" column.  Delete this amount.
6. Tab to a new split. 
7. Tab over to select an account.  Select Assets:Checking.
8. Hit Tab again.
9. Hit Enter.
10. Observe that gnucash has altered the account selected in step 4 to once
again be its original value - Assets:Checking.  However, you now have two splits
for Assets:Checking, and none for Expenses:Groceries.  This is incorrect.  

Once this transaction is entered, my checking account register now shows two
transactions (as a result of two splits referring to the checking account).  My
checking account balance is wrong.  My grocery expenses are wrong.

I expect that gnucash has changed that split back to its original account
because the transaction must have a split anchoring it to the current register's
account.

Note that hitting Tab vs. Enter is important in reproducing the above.  For
example, in step 6, if you hit Enter instead of Tab, nothing appears to happen.
 Hitting Enter again causes the transaction to disappear!  Also an incorrect
behaviour.  (Possibly this should be a separate bug, but I think the person
checking/repairing this one should make that decision.)

I see two options for repair.
First option: do not allow the user to change the account for the split which
anchors the transaction to this register.  This would be done preferably by
graying out the account selection for that split. Alternatively, gnucash could
post a dialog drawing this to the user's attention.

Second option: Scan the list of splits just before entering the entire
transaction to make sure that at least one split exists to anchor it to the
current register's account.  Show a dialog to call the problem to the user's
attention.  Don't enter the transaction until corrected.

I prefer the first option, and suspect it is less work (especially if you just
do the graying out rather than making a dialog).

In the meantime, I have a workaround: never change the account in the split
belonging to this register's account.  You can safely change this split's amount.