R_0..R_3 yields IndexedVariables after another ring reuses the same symbols

Nobody has claimed this yet.

This issue was triaged from [`bugs/dan/0-indexed-variables`](https://github.com/Macaulay2/M2/blob/388c1ff0ce30d83751dea7bc7eac77fdc1305dd7/bugs/dan/0-indexed-variables), one of the 857 files removed from the pre-GitHub `bugs/` tree by [`d2c8d27826`](https://github.com/Macaulay2/M2/commit/d2c8d27826) and catalogued in [#36](https://github.com/Macaulay2/M2/issues/36). **The commentary below was written by Claude (Claude Opus 5, via Claude Code)**, not by @d-torrance, whose account posted it -- please weigh it accordingly.

### The original file, verbatim

```text
-- -*- mode: M2 -*-
Macaulay2, version 1.3
with packages: ConwayPolynomials, Elimination, IntegralClosure, LLLBases, PrimaryDecomposition, ReesAlgebra, SchurRings, TangentCone

i1 : R=QQ[x_0..x_3];

i2 : class\(R_0..R_3)

o2 = (R, R, R, R)

o2 : Sequence

i3 : S=QQ[x_0..x_3];

i4 : class\(R_0..R_3)

o4 = (S, S, S, S)

o4 : Sequence

i5 : class\(R_0..R_3)

*** o5 = (IndexedVariable, IndexedVariable, IndexedVariable, IndexedVariable)

o5 : Sequence

The problem is here, where when v is changed, it is changed permanently! Also notice that the first time through, it evaluates v first!
So it's only the second time that v has the surprising value.

scan(join(apply(methods baseName,last),{MonoidElement}), BType -> if BType =!= Symbol and BType =!= IndexedVariable and BType =!= Holder then (
v := value;
bn := a -> (
r := baseName a;
if value r =!= a then v = identity; -- don't take values afterwards if either endpoint is not assigned to its base name
r);
err1 := lookup(symbol .., Thing, Thing);
BType .. Thing := (a,z) -> v \ (( try bn a else err1(a,z) ) .. z);
Thing .. BType := (a,z) -> v \ (a .. (try bn z else err1(a,z) ));
BType .. BType := (a,z) -> v \ (( try bn a else err1(a,z) ) .. (try bn z else err1(a,z) ));
err2 := lookup(symbol ..<, Thing, Thing);
BType ..< Thing := (a,z) -> v \ (( try bn a else err2(a,z) ) ..< z);
Thing ..< BType := (a,z) -> v \ (a ..< (try bn z else err2(a,z) ));
BType ..< BType := (a,z) -> v \ (( try bn a else err2(a,z) ) ..< (try bn z else err2(a,z) ));
))
```

### Where it stands today

Still reproduces, and one call earlier than the file reports.

```m2
i1 : R = QQ[x_0..x_3];
i2 : class \ (R_0..R_3)
o2 = (R, R, R, R)

i3 : S = QQ[x_0..x_3]; -- a second ring reusing the same symbols
i4 : class \ (R_0..R_3)
o4 = (IndexedVariable, IndexedVariable, IndexedVariable, IndexedVariable)
```

The file shows this happening on the third call; today it happens on the first call after the second
ring is created, and it stays that way for the rest of the session. So `R_0..R_3` stops producing
elements of `R` — it produces the bare indexed variables instead.

### Why it happens

`..` on ring elements is implemented in `m2/dotdot.m2` by taking the two endpoints back to symbols and
walking between them. When a second ring reuses `x_0..x_3`, the symbols now point at the *new* ring,
so the round trip no longer lands in `R`, and the code falls back to yielding `IndexedVariable`s
rather than erroring.

### Related, and deliberately kept separate

**#2771** covers the shadowing *warnings* in this area, which is a different complaint. Also relevant:
`tests/normal/dot-dot.m2:128` asserts the `IndexedVariable` fallback for a shadowed ring, added in
2009 — so a fix has to change a regression test that has stood for sixteen years, and the behaviour is
deliberate rather than accidental.

_{`open` · disposition `issue` · source of truth: [`bug-triage/catalog.tsv`](https://github.com/d-torrance/M2/blob/bug-triage/bug-triage/catalog.tsv)}

Reproduce the two-ring example first, then read m2/dotdot.m2 to follow how ring-element endpoints are converted back to symbols. Run tests/normal/dot-dot.m2, especially line 128, and determine the regression-test changes needed so the second-ring scenario has defined, verified behavior rather than unexpected IndexedVariables.

Written by the indexing model from the issue text.