Here's one of those little things that irritate me about bash, or more specifically its command line editing: its command history is (sometimes) mutable. Under at least some circumstances, you can overwrite a command that is in your history by going back to it (with search or cursor up) and editing it again. When you do this, the old version of the command is gone permanently; if you cursor back to it again, you see your freshly edited version.

(This doesn't seem to happen all of the time or on all of the machines I use bash on. So far I haven't had the patience to track down exactly what's going on.)

My mental model of shell history is that the past is immutable because it is, after all, the past; editing a past command should just result in a new command that just looks a lot like the old one. To have a sometimes mutable command history makes me nervous and twitchy; among other things, that old command may be the only version where I had something working (and I am editing it to try to improve things, which may or may not be successful).

I do have some sympathies with the mutable command history crowd. If you think of the command history as basically an edit buffer, it's more natural to change things in place, and even if you don't there are a bunch of interesting decisions (and painful programming) to do to make things come out right.

(Thinking about some torture test scenarios, I think you need to pretend that you have a mutable edit buffer and then undo all of the mutations at certain trigger events and insert any new command line at the end of the history. I maintain that one such trigger event should be clearing the entire line, however it happens.)