Please disregard my previous reply, Script Debugger is doing the correct thing. Thanks for posting this though because it allows me to show a subtle but important element of an AppleScript repeat with block: the control variable is local to the scope (in this case the on run handler). Take the following example code:
set i to 100 -- sets `I` property of global scope
set j to 0
repeat with i from 1 to 3 -- creates local `I`
set j to i
end repeat
-- local `I` persists for the remainder of the `on run` handler
{i, i of me, j} --> {3, 100, 3}
In the last line, there are two Is: a version of I local to the on run handler (containing 3) and a version I which is a property of the script’s object (containing 100).
This is all evident within the Script Debugger if you have debugging enabled. As you step through the repeat look you’ll see the two versions of I displayed:
Note the local (with yellow/orange right-hand indicator) and property versions of I.
When debugging is disabled, the SD UI displays the global I variable but fails to display the local version of I because it cannot (due to limitations in the AppleScript runtime) access the local version of the i variable.
My recommendation is to not create local variables that duplicate global or script object properties. AppleScript’s variable scoping rules are arcane and its best to avoid the problem entirely if you can.
One more thing: within the on run handler, variables created without explicit scope (i.e. use of a local statement) are properties of the owning script object. By contrast other handlers create local versions of their variables by default unless scope is explicitly set with a global statement - as I say above, AppleScript’s variable scoping rules are arcane.