Yeah. I like it from the point of view of "think new thoughts". It's an interesting thought. Let me highlight that with a few more words here to indicate that I don't just mean that as a polite sidebar; it really is an interesting thought. There may be something there.

But as presented, the code complexity scales like a nightmare; it makes the worst Ruby monkeypatching look sane. Something would have to be done about that before even a toy implementation could be done, because this will fall apart very quickly.

When you give away structured programming, you give away its benefits too. One of its benefits is that in a structured program, you can freeze a thread at any point and you have a clean mechanism for determining from there what its stack trace is, and all the relevant scopes it has access to and could be affecting it. In real code, this process may produce a very large number of variables and stack levels, but it'll still be a fraction of the program's possibilities. This is how structured programming helps us approach programs as structured slices of the code base, instead of a holistic view of the entire code base at once (this is the true reason goto-based code was so evil in the day; you could never do this analysis). This approach throws this away. That is not intrinsically wrong. But I'm not convinced at this time that the compensating features we get make up for losing that clarity, especially because the benefits are going to have terrible scaling problems as presented.

If someone was going to pursue this, this is the angle I'd take; how do I freeze my program and determine what is affecting the behavior of the current execution trace? Assume an arbitrarily powerful debugger attached to your running process, as long as it doesn't "magic" anything into existence. I can see sketches of ideas in my head, I am by no means saying this is unsolvable. But I think it's something I'd need to see laid out a bit more before I got too excited. To anyone thinking about this, I'd advise you to also not forget scale. Anything works for 100 lines of code. I need you to present me with something that can make sense of when I'm running, let's say, thousands of these advisory functions at a time on a single question. Structured programming has an answer to that; being a thousand layers deep in a stack trace may be a lot for a human to take in, but nevertheless, the procedures that structured programming provides will still give you answers. (And I'm not asking for the solution to work any better than structure programming does in that case. Thousands of anything is irreducibly complicated. But it needs to at least give me understanding in the ballpark of what I have in a thousand-deep stack trace.)