array takes the count and the type; the directory keeps naming the module

NEXT.md

@@ -495,6 +495,40 @@ run one lane at a time; item 4 is disjoint and runs alongside any of them.
 Deliberately not scheduled: the JS backend and header-based C interop, both large and neither blocking current work; a
 debug tracking allocator, which is the leak safety net and a good candidate whenever it is wanted.
 
+## Decided in discussion — the array constructor and the module system
+
+**`(array 4 rl/Vector2)` makes a fixed array; `[4 T]` stays the type syntax.** The problem this solves: a `let`
+binding takes no type, so `(let [pts [4 rl/Vector2]] ...)` reads `[4 rl/Vector2]` as a two-element array *literal* and
+fails with *unknown name rl/Vector2*. It cost 32 hand-written `Vector2`s in one raylib example.
+
+`[4 T]` is not a special syntax — it is the ordinary type syntax and already works everywhere a type is expected:
+`(defvar points [4 rl/Vector2] ...)`, `(defn draw [pts [4 rl/Vector2]] ...)`. A `let` binding is the single position
+with no type slot, which is the whole of the bug.
+
+`(zeroed [4 rl/Vector2])` was proposed first and rejected on how it reads: in argument position the bracket form is
+unambiguous to the *parser*, but it still looks like a two-element vector to a person. `(array 4 rl/Vector2)` says what
+it does with the count and the type as plain arguments. `zeroed` keeps its existing job — an empty thing of whatever
+type the destination wants — and `array` is the one that is told.
+
+**The module system stays as it is: the directory name is the module name.** No `package foo` line at the top of each
+file. Confirmed against Odin, which requires the declaration despite having the same one-package-per-directory rule —
+`package os` appears in 85 files, all of them in `core/os` — so the line is ceremony that buys only the ability to
+disagree with the directory name.
+
+What the rule already gives, and what was checked in conversation: **several files in one directory are one module**,
+which is the case directory-as-package exists for; **a loose file is a module of one**, so several modules can sit at
+the same filesystem level without a directory each; and two modules cannot share a directory, which is also true of
+Odin.
+
+**Acyclic imports are kept deliberately, not inherited by accident.** Odin forbids import cycles and so should this:
+a definite package order is what the macro expander will need later, since every `defmacro` must be compiled before
+anything that calls it. Nested import paths not being real nesting — Odin's `core:math/bits` is a separate package
+rather than a submodule of `math`, with no re-exporting — was reviewed and accepted as fine.
+
+**Still missing, and this is the real gap:** `load.ml` does not support **a package importing a package**. It is
+listed among the milestone-4 loose ends. Until it lands a project is an entry file plus one flat layer of libraries,
+with no library depending on another.
+
 ## Blocked and unfinished
 
 Everything below was found, decided or half-built and then stopped. Each says what blocks it. Nothing here is a