Bug

When two distinct type variables map to the same concrete type during monomorphization (e.g. A→Int, B→Int), slot references like @Array<A>.0 and @Array<B>.0 both become @Array<Int>.0 — but they should be @Array<Int>.1 and @Array<Int>.0 respectively, because there are now two parameters with the same slot type name.

Example

forall<A, B> fn map_go(@Array<A>, @Fn<A, B>, @Int, @Array<B> -> @Array<B>)

With A=Int, B=Int:

• @Array<A>.0 (param 0, only Array<A>) → should become @Array<Int>.1 (second of two)
• @Array<B>.0 (param 3, only Array<B>) → should become @Array<Int>.0 (first/most recent)

Without reindexing, both become @Array<Int>.0, producing wrong values at runtime (silent data corruption).

Impact

Any generic function with multiple type variables that map to the same concrete type produces silently wrong results. This is a correctness bug — the function compiles and runs, but reads the wrong parameter values.

Fix

Added _build_reindex_map to monomorphize.py that detects namespace collisions during substitution and adjusts De Bruijn indices. The reindex map is computed before substitution and threaded through _substitute_in_ast. Fixed in the feat/array-operations branch.