Just tested this, in XTerm and in Conversations (by starting a new SMS). Works fine for me. If it is a bug, it's not in the normal hildon input method.

I suspect it's in ukeyboard, then, because I don't have that. The only other keyboard changing stuff, I think, is Bluetooth HID (specifically the keyboard stuff the HID scripts bring in).

What's happening with you is pretty easy to figure out mathematically. Whatever your applications have changed in the virtual keyboard aspect of the input method, has made it incapable of changing position in the text.

So when you type "123456789" and delete 456, and replace with abc, trying to get "123abc789" you should get "123456abc". Because when you go to a different spot and backspace the "456" it recognizes that you deleted three characters, but it doesn't realize you moved from the end of the text. So instead it deletes the last three characters, and types from there.

So when you type "The quick brown fox" and delete "brown", it backspaces six characters from the end - f, o, x, (space), n, w. (Six because when you delete "brown" you presumably delete one of the spaces next to it.)

The same process happen with your other example. "The quick brown fox", when you delete "quick" it backspaces five (space doesn't get deleted because I assume you're not deleting the spaces since you're about to write another word in) characters from the end: "n fox". Then it adds what you type instead of quick - "slow", resulting in "The quick browslow". Then you replace brown with yellow, which it registers as "delete five characters, add 'yellow'". Thus, "wslow" gets deleted, yellow gets added to the end.

Guessing whoever coded whatever is responsible didn't logically think through some part of how the text entry works, and thus didn't realize that when editing something other than the last part of the input string, it would glitch like that. *Shrug*