Spyder Editor run system ↔ IPython console kernel: namespace and debugger state across restarts and external connections

The integration boundary between Spyder’s Editor run system and the IPython console kernel determines where code executes and how Spyder reflects kernel state in Variable Explorer, plots and the debugger. Per-file run configuration can target the current console, a dedicated console, or an external system terminal, which changes which kernel namespace receives the execution.

Kernel lifecycle is managed separately from the editor. After a restart or reconnect, Spyder’s UI components must resynchronize with the kernel’s current namespace, and connecting to an existing kernel introduces an ownership boundary where Spyder can drive and inspect the kernel but may not control its lifecycle in the same way as a console it created. Breakpoint binding also depends on file path, interpreter environment and working directory alignment between editor and kernel, and the user-module-reloader preference alters import semantics across repeated runs in a persistent console.

What behavior is expected for Variable Explorer and debugger state when a file is run in a dedicated console versus the current console after a kernel restart? Does connecting to an existing external kernel change which Spyder-side lifecycle actions are available for that kernel? What is the interaction between per-file run configuration and user-module-reloader when the same file is executed repeatedly in a persistent console?