The REPL renderer is most of println

plan.org puts a compiler-provided, type-directed println at milestone 5: a
structural printer selected or emitted per concrete instantiation, Ptr printed
as an address rather than followed, depth and length bounded. That is a
description of the renderer C-x C-e already has - same walk, same refusals, the
same three bounds - pointed at flan_dev_emit and the wire instead of at stdout.

Recorded next to the renderer so it is not built a second time. What println
needs on top is a stdout sink, a builtin that takes its printer from the
argument's type, and the any/Error cases, which have no compile-time type to
walk.

NEXT.md

@@ -791,6 +791,17 @@ socket. The read is safe without a handshake because `flan_dev_result` bumps a
 generation counter last; the daemon waits for it to move rather than assuming
 the program has reached a frame boundary.
 
+**This renderer is most of `println`**, which is worth knowing before anyone
+schedules it. plan.org describes a compiler-provided, type-directed intrinsic
+that selects or emits a structural printer per concrete instantiation, prints
+structs, fixed arrays and options structurally, prints a `Ptr` as its address
+rather than following it, and bounds depth and length. That is a description of
+what `Session` already does for `C-x C-e` — same walk, same refusals, same
+three bounds — aimed at `flan_dev_emit` and the wire instead of at stdout. What
+`println` needs on top is a stdout sink, a builtin that takes its printer from
+the argument's type, and the `any`/`Error` dynamic cases, which have no
+compile-time type to walk. Not the walk itself.
+
 The renderer is a **compile-time walk over the type**, emitting a piece at a
 time through `flan_dev_emit`. Piecewise because a struct is its fields with
 punctuation between them, and concatenating that in generated IR would need an