Running clojure-test-suite surfaced an Option A regression (3971 -> 3957),
isolated to two root causes, both around lazy seqs:
1. nil first element wrongly read as end-of-seq. core-empty?, core-seq, and
core-reverse tested a lazy seq's emptiness with (nil? (ls-first coll)) — but a
lazy element may legitimately be nil. With Option A's lazy `drop`, the `case`
macro's (empty? (drop 2 clauses)) hit a nil-first lazy seq at the `nil`
case-constant and collapsed the rest of the case (incl :default) to nil —
breaking 14 case.cljc assertions. Now they realize one cell (seq-done?-style)
instead of trusting ls-first.
2. lazy transformer over a non-seqable silently yielded empty. The eager path
threw (realize-for-iteration on a char/number errors); Option A's lazy-from
returned nil, so (first (remove nil? \a)) gave nil where Clojure throws.
lazy-from now rejects non-seqable scalars (number/boolean/keyword/char/symbol)
with "Don't know how to create ISeq from: …".
Result: suite 3971 -> 3981 pass (net gain), clean files 45 -> 66 (Option A makes
seq?/vector? match Clojure across many cross-dialect files). Baseline raised.
Gate: conformance 258x3 (+5 regression guards), lazy-infinite 44/44, suite
3981/66, fixpoint, self-host, specs+unit green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
9a9de08047