When one accidentally changes the encoding of the file, the asked for feature would help to detect such a mistake. A different encoding should be highlighted similar to other diffs to easily spot the mistake.

Alternatively, regarding the problem of accidentally saving a file in the wrong encoding and not discovering the mistake because SmartGit diff view does not show a change although certain bytes in the file might have changed, an option similar to the lowe-level property text.detectUtf8WithoutBOM could help. One that semantically means "always honor the 'Text File Encoding' setting of the project", preventing SmartGit from ever trying to guess the character encoding of a file.

I completely agree in general. I envisioned that in general no dialog would occur after a selection change.

I imagine it like this: When the user modifies a text in the Changes view, she really explicitly wants the current 'read only viewer' (which can be closed at any time) to become a simple 'text editor'. When this 'text editor' is closed while having unsaved changes relative to the underlying file, e.g. due to selection change in the Files view, IMHO it is appropriate to show a modal dialog asking what to do with these unsaved changes. The purpose of this simple text editor is to make tiny modifications, typically fixing small errors spotted while inspecting changes using the current Changes view. When you want to do more serious editing, you should use another editor.

I also would like to edit the displayed content (from index or working tree, obviously not HEAD) of the Changes view directly. Opposed to having to open the index editor, 'tediously' visually search / scroll to the place I want to edit, close the editor again. After all, isn't one important purpose of the Changes view to check/verify the modifications I made to the working tree and/or index? Well, checking means the possibility to spot errors. And if I do spot an error, I'd like to fix it right away.

So effectively the Changes view would no longer be a read only text view, but a simple editor. Actually two, one for each side (unless the underlying file is from HEAD). I imagine that as soon as the text has been edited, it visually indicates, as Thomas said, that the displayed contained is modified relative to the underlying file (working tree or index). You cannot 'navigate away', e.g. by selecting another element in the Files view, until you explicitly save or discard your modifications. I.e. each side of the changes view would need two additional buttons: save and discard. If you try to 'navigate away' anyway, a Dialog offers to save/discard/cancel.