I repeated Tal's experiment, on Windows, and added more.  I list below multiple issues related to code context and scrolling, and possible solutions.

1: two geometry modes.  After the text height is set on start up or by restore height, CC height is added to the fixed text height, making frame (and window height) vary.  After the window height is set by the user or zoom height, CC height is subtracted from the frame height, derived from the window height, making text height vary.

I don't remember noticing such switching between add and sub modes when CC height was fixed, but I presume it occurred. (I don't have pre-3.6.8 3.x to check.)  But it is now confusing and a nuisance.  I think we should prefer sub mode because add mode would undo correct zooming when zoomed, results in status line artifacts when row and column spaces temporarily left black, and is overall more obnoxious.  Perhaps we could do this by setting window height after setting text height.

2. text top.  With CC height varying, the top of text bobs up and down regardless of mode.  My initial opinion is that the visual effect is muted if the context foreground color is the same as normal text and the background similar.  Or maybe vice versa.  We might reconsider the current default, or add a doc recommendation.

We might experiment with border styles and their affect on the boundary between CC and text.

3. text bottom.  In sub mode, this stays put, but there is some white flashing that for me is only noticeable with a dark theme.  What happens seems to be this.  We start with n exposed lines of text and k lines of context. We change the exposed text, still n lines, by scrolling, whether with arrow key, mouse wheel, scrollbar arrow or trough clicks, or slider drag.  (No scroll arrows on my Macbook Air.) Suppose CC adjusts the context and the result is k' < k lines.  The text box increases by d = k-k' lines and the existing n lines are moved or copied  up.  In either case, the d lines at the bottom get a white background for a fraction of a second before being syntax colored.  

There are two oddities.  First, the padding between border and text line ends remains dark.  Second, after moving up and down a line where flashing happens, it sometimes stops after about 3 repetitions.  (Example editor.py, CC on, line 41 top line visible, move down and back up, repeat.)

Perhaps making sure that both toplevel and frame have the proper background will solve the issue.  I don't know the colorizer well enough to know whether it is relevant here.

4. scrollbar slider.  When the scrollbar jumps up or down with the text, 
the slider necessarily jumps up or down with it.  (I am ignoring slider size changes in sub mode, which will nearly always be minor in comparison.)  This is most obvious (and obnoxious) to me when dragging the slider, which I seldom do.

One way to prevent the bouncing is to fix the CC height, like it used to be.  Rather than revert, I would add a min height, so that min == max means fixed.  Another way to prevent the bouncing is to avoid mixing CC and scrolling, especially dragging.  Adding a CC hot key would enable quick looks at current context while mostly having it off.  With line numbers on, I think that this would be even more needed.

5. arrow keys (not related to CC).  With Notepad++, down arrow scrolls through editor.py (1722 lines), from beginning to end, at about 30 lines per second.  With IDLE on my machine, down arrow goes a few hundred lines at about 23 lines per second, with the cursor blinking as normal.  But then the cursor blinks off, and and scrolling stops for perhaps 2 seconds.  When the cursor comes back on, the file jumps about 50 lines.  This happens a few times, and the the cursor blinks off and stays off for at least several seconds.  It is like the key got tired and went to sleep.  If I then move the cursor some other key, arrow key works again, for a while.  Anyone else see anything like this?

The tests needed would mostly be suggestions added to an htest.