While looking into #670 we found that setting a variable at a debugger stop doesn't behave the way the VS Code Variables view suggests, in either debugger. This issue collects the findings; fixing it needs design work first, ideally together with merging the two debugger implementations.

Intended behavior: setting a variable does what the Variables view promises: it changes an existing variable in the scope it is shown under (Local, Test, Suite or Global) and never creates one.

What happens today

• VS Code debugger: set_variable looks up the stack frame entry, but the entry's context is the suite's shared ExecutionContext, and context.variables.current is the innermost scope at the stop. Editing a variable of an outer frame, or one under Test, Suite or Global, therefore writes the value into that innermost scope, and the edited variable keeps its old value. This has been the case since setting variables was added in 2021.
• robotcode robot-debug: .set writes into the selected frame's own scope, so a test or suite variable changed there is only shadowed in that frame. It always stores the value as a string (.set ${x} 7 stores '7'), and list and dictionary variables can't be set.

Why this needs design work

Robot Framework's scopes are copies: the test scope and every keyword scope start as copies of the suite scope. A new value written into the suite scope alone doesn't reach the copies that already exist. Set Suite Variable and its siblings write the scope and every scope up to the current one, which also overwrites local variables with the same name.

To decide

• Which scope a plain set targets, and whether the command-line debugger needs a way to name it.
• How the copies in inner scopes get the new value.
• How the entered value is interpreted: as an expression, as in VS Code today, or literally.