@gfb drracket (tries to) keep(s) a strict separation between the code that implements itself and the program that’s running in the user’s program. The simplest reason for that is that DrRacket shouldn’t be required to run your program. This isn’t quite the “bright line” that we might hope it is, but it sounds like you’re trying to break it and so perhaps it is better to think about another way to achieve the effect you want.

It’s for a self-contained teaching language with (DrRacket) environment, and only for the Interactions area. For example, an inline algebraic stepper whose view/control is affected by preferences which are worth changing without rerun (and even before returning to the prompt). The low-level access is sufficient for now, but there are more subtle HCI aspects I’d like to explore if we didn’t have to use an extra-linguistic mechanism to set preferences.