Here is the blunder

>>>  exec("def foo:")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    def foo:
           ^
SyntaxError: invalid syntax
>>>
--------------
See that? def foo: is actually a valid physical statement.

in 'c' it would be:

ebal("{")

What does it mean to the eval routine? It means, increment the block count. To the compiler, it means create a daughter link on the expression graph and prepare ti full it with siblings.

Now, the eval statement should keep local variables on the local stack, and I looked at local dict to see if eval had anything like an indent count. No.

By the way, c has the same problem.  I would think the interpreter maintains no variables on the stack, almost every thing would be in dictionary arguments.  But '{' is a valid unitary operator, and statement,  it means increment the block count.

So, it is a puzzle, likely elegantly solved.  Possibly some Python API, or a simple built in to simulate the call operation and the debugger tracks indent counts.  Something, and it will be fun to find out.

Normally, the debugger puts call break points right in the source code, then it can let pyton run free, it will hit the break and make a callback to the debugger. But then, the code on he screen does not match the code running, so you have to do line number checks to replace the replaced code when the user scrolls through a breaked line.  Hmm...

Any way, it does what I need as I ponder the most simple of fixes possible.