Rereading this, I see interlocked behavior (implementation bug) and enhancement (design bug) issues. I have been focused on just the former. 

Consider the exception traceback in msg107441: there are *two* filename, line# pairs. Now consider this warning for tem.py
---
from os import listdir
from warnings import simplefilter
simplefilter('always', DeprecationWarning)
s = "a = 2\nlistdir(b'.')\n"
exec(s)
---
Warning (from warnings module):
  File "C:\Programs\Python34\tem.py", line 2
    from os import listdir
DeprecationWarning: The Windows bytes API has been deprecated, use Unicode filenames instead
---
There is only *one* filename, line# pair. If we accept that limitation, what should the filename be? An actual filename (if possible) or "<string>"?  Considered in isolation, I think the first (the current choice) is better, because it is essential for fixing the warning (as stated in msg107441). Hence I rejected Greg's first 'solution'.

Similarly, what should the line# be?  The line number of the exec statement or the line number in the string of the statement that caused the warning?  Considered in isolation, the second (the current choice) seems better; the string s could have hundreds of lines and it would be really helpful for eliminating the warning to know which one generated the warning. I presume the author of exec had a reason such as this. Hence I rejected Greg's second solution.

The two isolated answeres make for an inconsistent pair. The could be manageable, but...

The third question is what line, if any, should be printed. If possible, the line in the string that caused the problem seems best. (But note that this line is missing from the exception traceback.)  Second best is the line of the exec call (which *is* in the exception traceback).  The current behavior, resulting from warnings not knowing that the filename and lineno it gets do not form a pair, is worse than nothing and I agree that it is a bug.

I am not sure what to do. The exception/traceback/warning system was not designed for exec.