Puppeteer 20 AbortSignal: aborted navigations reject with generic Error instead of TimeoutError

Context

Since Puppeteer 20.0.0, page.goto, page.waitForNavigation, page.waitForSelector, and page.waitForXPath accept an AbortSignal as the first argument, so in-flight work can be cancelled with an AbortController. This is a change from 19.x, where cancellation required racing promises manually.

The discrepancy

When a timeout (for example via page.setDefaultNavigationTimeout or the timeout option) is exceeded, Puppeteer rejects with a TimeoutError. When the same operation is cancelled via AbortSignal, it reportedly rejects with a plain Error('The operation was aborted') rather than a dedicated AbortError or the same TimeoutError. This was observed against the v20 behavior and should be re-verified against the current release, since error classes have changed across versions.

Why it matters

Test harnesses and retry logic often branch on instanceof TimeoutError to distinguish slow pages from real failures. A generic Error on abort forces string matching on the message, which is brittle across upgrades.

Questions

1. Is the generic Error on abort the intended stable contract, or is a dedicated abort error type planned?
2. Should cancellation and timeout be handled as the same category in retry logic, or kept distinct?
3. Is matching on the message string safe across minor versions?