Globals go per frame; watching is its own question

DISCUSS.md

@@ -19,8 +19,17 @@ the machinery is there and the question is mostly one of presentation — its ow
 the stack, or a separate buffer.
 
 The real question is **which** globals. A program has hundreds and a listing of all of them is the backtrace problem
-again: the thing you want is buried by the thing you don't. Worth considering: only globals the stopped function
-mentions, which the compiler knows; or a filter; or a pinned watch list.
+again: the thing you want is buried by the thing you don't.
+
+**Direction settled in conversation: per frame, beside the locals.** Opening a frame shows that function's locals *and*
+the globals that function references. Each frame answers for itself — frame 0 shows what the innermost function touched,
+frame 3 shows what that one touched, and a global appearing in several frames is informative rather than redundant,
+because it says the whole chain was working with it. The compiler already knows the reference set per function, so
+nothing is guessed and nothing is configured.
+
+What this deliberately does not solve: a global nothing in the current frame names but that you still want visible —
+the sand grid while stopped in a helper that never mentions it. That is watching, and it is item 10 rather than part of
+this.
 
 ## 2. The break buffer should appear by itself
 
@@ -132,3 +141,26 @@ Three findings from an earlier review, recorded in `NEXT.md` and not yet in `pla
 Also open and related: whether a *condition* can be a class, which decides whether handler matching has one path or two.
 `NEXT.md` records the argument; decision 4 there took the cheaper parent-link route for now and explicitly left real
 inheritance possible later.
+
+## 10. Watching variables
+
+Raised while designing item 1, and deliberately separated from it.
+
+Item 1 shows globals *per frame*, chosen by what the code in that frame references. That is the right default and it
+cannot cover the case where the thing you care about is not named by the frame you are standing in — stopped deep in a
+helper, still wanting to see the grid.
+
+So: a way to say "always show me this", surviving a resume and the next break.
+
+Questions it opens:
+
+- **What can be watched.** A global is easy — it has a name and an address that does not move. A *local* is harder: it
+  belongs to a frame that is gone as soon as you resume, so "watch `y`" either means a different `y` every time or means
+  nothing. A watched expression — `(at velocity 40 12)` — is the most useful and the most expensive, since it has to be
+  compiled and run in the program each time, which is what `eval-expr` already does.
+- **Where the list lives.** Per project, per session, or in the file. A watch list that vanishes when Emacs restarts is
+  one you stop using; one in the repo is one you accidentally commit.
+- **When it updates.** Only on entering a break is cheap and probably enough. Live-updating while the program runs is a
+  different feature — closer to a HUD than a debugger — and worth not conflating.
+- **Whether it belongs in the break buffer at all**, or in its own window that is useful while the program is *running*,
+  which is arguably where a game developer wants it.