Robert, that's what I initially thought too and it's indeed mostly so but not 100%: the old style %RI is actually calling the new style ROUTINE^%R, with Audit classes and all. Just no source control class suspenders smiley . I see no technical reason not to have them in ^%R but they are not there. The ZSAVE implementation is not available.

So this is why I am trying to tackle this problem from the Audit side. Any ideas? I am thinking of a process monitoring the audit trail records but I don't quite like this solution. In any event, is there anything beyond monitoring?

That's exactly the problem: the new breakpoint is reached but no yellow box and the cursor stays at the routine's first line. The code is executed though because the variable set right before this single breakpoint gets defined correctly as per Watch. I did follow your instructions except I still used the corrupt routine.

I doubt I can reproduce this corruption intentionally because that requires understanding why it got corrupted in the first place and that is still a mystery to me.

Robert, a bit more info after I tested a bit more:

1) The first program above, TestAG exhibited the same corrupt debugging behavior when I set it up as debug target for another project however this another project started debugging alright when I switched to a yet another debug target:

2) Test in this comment above leads me to think that the corrupt debug behavior might be associated with a program more than with a project. I don't think it is associated with the old style b break since it behaves correctly, the same as before.

I am not sure I am falling into the .obj code with this problem but maybe I do.  Just to be clear what is happening and what is not, a couple of screenshots.
1) TestAG^TestAG is the debug target, hand-written routine, and I pressed Go once, so presumably the debugger now sits at this breakpoint. However, no yellow box and the cursor is one line up. Shift+F11 does not make the cursor or the yellow box to appear anywhere else (I have other breakpoints too).

2) This is normal behavior. last is the debug target and the cursor correctly stops at the programmatic breakpoint with a suitable yellow box.

So any advice how to fix it?

@Alexey Maslov The ultimate goal is to create identical globals on 2 different machines with a single run, on demand.  I can run code on the first machine, then export global creating code which changes regularly, reconnect the Studio to a different machine, import code, then run it again. This is decidedly not a single run. I can also export and import global too, of course. I am willing to learn functionality that would be faster to deploy than these two approaches. Ideally as fast as ZN which unfortunately works on the same machine only but I might be wrong about that.