G-055 detail: lseq operand typing probe - indexexpression fit vs expr syntax validation (user query 2026-07-13)

Assisted-by: harness=claude; primary-model=claude-fable-5; api-location=anthropic.com

goals/G-055-tclcore-regen-workflow.md

@@ -118,6 +118,19 @@ other commands including the multi-form ::after.
     form's expr-typed end accepts the word 'count' - real lseq resolves it as the
     start_count form. Tightening the expr operands (or making them
     version-conditional per TIP 746 below) removes the false candidate.
+    Probed 2026-07-13 (user suggestion: -type indexexpression instead): a poor
+    lexical fit for lseq operands on 9.0.3 - indexexpression (lindex-style
+    int/end/end+-N/M+-N) UNDER-accepts real-valid operands 1e2, 2*3, 6/2,
+    sqrt(9) and the man page's own {[llength $l]-1} idiom, and OVER-accepts
+    end/end-1 (real lseq rejects); number|indexexpression repairs only the
+    number literals. The precise discriminator is expr SYNTAX validation: the
+    problem words (count/to/end) all fail Tcl's expr PARSER as invalid
+    barewords while every real-valid shape parses - but a validator must parse
+    without evaluating (operand exprs may contain command substitution), i.e
+    tclparser 'parse expr' (G-069/G-070) or equivalent, not catch{expr}. Also
+    noted: count-position operands reject doubles where start/end accept them
+    ('lseq 1.5' errors, 'lseq 1.5 3.5' works) - a value-dependent constraint no
+    lexical type expresses.
   - TIP 746 (user-flagged 2026-07-12,
     https://core.tcl-lang.org/tips/doc/trunk/tip/746.md) removes the expr
     behaviour from lseq operands in Tcl 9.1: the lseq model's number|expr operand