The prelude predates the allocator; a second tier waits on macros

NEXT.md

@@ -490,6 +490,29 @@ hand-written backend is needed at all.
 
 It is research first, not building. The batch below stays valid and none of it is blocked by the question.
 
+## Queued: a second tier of the standard library, after macros
+
+Blocked only on `lib/prelude.ml`, which the macro lane holds. Start it when that merges.
+
+**The gap, stated plainly: the whole prelude predates the allocator.** All 44 functions are slice-based and
+allocation-free, because when they were written there was nothing to allocate from. `Vec` and `Map` now exist, so a
+second tier is possible — functions that *return new things* rather than writing into a buffer the caller supplies.
+
+Wanted, in rough order of how often it will be missed:
+
+- **String building.** A `Vec u8` builder, `join`, and a `split` that returns a `Vec` instead of the
+  `split-next!`/`split-on-byte` iterator dance the current one requires.
+- **`Vec` algorithms** — `map`, `filter`, `reduce`, and a `sort` that is not integers-only. `sort-i32!` is the only
+  sort there is.
+- **`Map` helpers** — keys, values.
+- **Maths gaps**: `atan2`, `pow`, `clamp`. `sin-f32`/`cos-f32` exist with the caveat that IEEE-754 does not make them
+  correctly rounded, so native and wasm32 may differ bit for bit; anything added here inherits that and should say so.
+- **Number formatting with a precision.** Note the sharp edge that constrains this: `flan_i64_to_bytes` and friends
+  share one `static char scratch[64]`, so two formatted numbers cannot be held at once. A `Vec`-returning formatter
+  would not have that problem, which is an argument for building it.
+
+Already present and easy to miss: an **EDN parser**, at `vendor/edn/edn.flan`.
+
 ## The next batch, in order
 
 Agreed at the end of 2026-09-12. Ordered by priority, not by size. Items 1-3 and 5-6 want the compiler core and should