Technically speaking:

• I think being able to connect "bricks" is a good idea ... but ...
• we need work on polyscript side to share the same environment ... dare I say that could be either out of the main thread or the worker one, and it should be transparent for the user as long as it's clear that some environment can run only in workers (terminal with a blocking input or editor which is by default in a worker)
• the terminal story is a bit weird ... anyone can write as much Python code as they want before the code.interact() call is executed ... referring a terminal to an existent piece of code is also already possible: you have a <pre id="terminal-dode"> tag, as example, with code in it, you can eval that in Python before asking to code.interact()
• the editor that pollute the already known shared interpreter is indeed an interesting case, specially because we don't have a way to grab code from a foreign script but we could ... that could be a source attribute to me, so that an editor evaluate that code once before eventually evaluating its own code after ... this should fix all the things

In short, all I am saying is that there are ways to achieve the idea of a shared env already but of course this requires examples and documentation but it's possible, except for the source attribute in the editor that could, indeed, land in the next release, if we want to.

Any other approach requires a lot of tweaks in the polyscript module but hell yeah if I think those convoluted tweaks are cool and needed indeed!

A related question came up organically in response to @sadukie's talk at PyOhio 2023 - "If I define functions and data and stuff in my script, are they available in the [editor]?"

As you say Andrea, there's API/UX considerations here, but the theme of "I want to write code in a <script> tag and interact with it via an editor" is surely worth pursuing.