I am attaching another test file, y.py, which shows that the cause of discrepancy is outside of the trace module. The traced function is the same as in x.py only with 5 iterations instead of 10 for brevity, but instead of using trace module, I am registering a custom trace function like this:

lines =	[]
def tracefunc(frame, what, arg):
    if what == 'line':
	lines.append(frame.f_lineno)
    return tracefunc
sys.settrace(tracefunc)

3.1s: [3, 5, 3]
3.1g: [3, 5, 3, 4, 4, 4, 4, 4]
3.2s: [3, 5, 3, 3, 3, 3, 3, 3]
3.2g: [3, 5, 3, 4, 3, 4, 3, 4, 3, 4, 3, 4, 3]

Interestingly, this shows that effect of computed gotos is the same in 3.1 and 3.2 - adding a line event from "for i" line.

This situation illustrates the reason why I wanted to use synthetic events to test the trace module rather than events generated by settrace  machinery.  Apparently these differences have nothing to do with trace.py and everything with ceval.c.  If it is important to maintain stability of trace events between python versions, tests (with appropriate sensitivity) should be added to test_sys_setrace.

On the other hand, there are a lot of things that can go wrong in trace.py - extracting code information from frame, divining the method and class names etc.  Ideally, this logic should be tested without reliance on details of event generation.