Your comments

Yes, I was proposing it as a new feature, but only because I had no idea that it had been already implemented. As soon as I figured that out, I found the setting in the default prefs, but thanks for the detailed explanation :) It is slightly different from what I described above, but otherwise it's exactly what I've been missing.

It seems for some reason I'm not seeing any indentation highlighting, so I was not aware it ever existed. Forget about this thread.

If you're on line 3 (the "for" statement), the third indentation guide should be highlighted, because that line is indented at the same level. The algorithm should be something like:

  1. get leading whitespace of the current line (e.g. eight spaces, for line 3 in the example)
  2. calculate the indentation level that whitespace corresponds to (e.g. with a 4-space indentation, eight spaces gives us level 2 indentation)
  3. highlight the indentation guide at the calculated indentation level (e.g. level 2 indentation => third indentation guide, because the first guide is for level 0)

Perhaps "select more" should select next find match when find results are displayed?
With row-selection we have bare click vs shift+click; for the column selection you're suggesting that we should have alt+click vs alt+click for the two different selection modes? alt+shift+click for the "select to here" would be more agreeable.
Simply saving the file updates its modification timestamp, even when there was nothing changed. At least that's the behavior I see on OSX.
+1, though this would need some configuration for choosing the layout for the new group.
Against, or at least should be configurable. I enjoy the "preview" mode immensely, and use it constantly — it is often useful to glance over a file without it polluting the tab bar, and if any change is needed the transition from "preview" to "editing" is very unobtrusive.
No, it shouldn't, or at least it should be configurable. This behavior would rely on your cursor already being in one corner of your desired box selection, and to me it seems that in most cases this will lead to unexpected selection behavior and confusion.
It actually does. If the cursor is at the start of the selection (for example, you have selected with shift+left), shift+clicking before the selection will keep the cursor at the start of the new selection as well, just as shift+clicking after the selection would move the cursor if it was already at the end of the selection. As with your issue with the visible cursor in selection, I fail to see how this would confuse anybody. My guess is that other OSX apps also behave in the same way, but it is not obvious due to the cursor hiding when there is an active selection.