[Tracking] Copilot SDK v2.0

Start by reviewing the native sub-issues and the historical issues #1934, #1930, #1976, #2048, #2202, #2395, #2463, and #2505; no implementation files or tests are named here. Map each change set to the API, runtime, reliability, and migration work it requires. Done means every planned item is implemented, resolved, or explicitly reconsidered, with integrated tests, migration documentation, and an approved release plan.

Goal

Deliver the API, runtime integration, reliability, and migration work required for Copilot SDK v2.

The work carried forward from #1934 represents maintainer intent: these are jobs we expect to do for v2, not an open-ended list of ideas for contributors or agents to accept or reject independently.

Scope and presumption

The native sub-issues group the historical work into coherent change sets. Work listed in them should be implemented unless current investigation produces concrete new information that changes the situation, for example:

• the work has already been completed or made obsolete
• the proposed implementation no longer fits the current architecture
• a required change belongs partly or wholly in another repository
• a newly discovered compatibility, feasibility, or product constraint warrants reconsideration

When that happens, document the evidence and proposed change of direction on the relevant issue. Do not drop, defer, or close planned work merely because another approach seems preferable. A maintainer should confirm any decision not to deliver an item that was carried forward from #1934.

Work that requires github/copilot-cli changes remains part of the intended outcome until the dependency is explicitly reconsidered. Create or link the corresponding runtime work rather than treating the repository boundary as an automatic reason to omit it.

This tracker concerns the SDK package major version. It does not track SDK-to-CLI wire protocol v2.

Working agreement

• Investigate each change set enough to implement it correctly and identify existing or external work.
• Keep breaking v2 pull requests open and based on main until maintainers approve the integration and release plan.
• Authors may rebase those pull requests independently while main continues to ship v1.
• Do not merge a breaking v2 pull request into main until maintainers approve the approach.
• Merge compatible v1 groundwork where it reduces the eventual breaking change without changing supported behavior.
• If implementation uncovers a reason to change scope, report it with evidence and wait for maintainer direction rather than deciding unilaterally not to proceed.

Release gates

• Every planned item is implemented, demonstrably already resolved, or explicitly reconsidered by maintainers based on documented new information.
• The accepted changes are tested together.
• Maintainers have agreed an integration plan that protects remaining v1 releases.
• Breaking changes and migrations are documented per SDK.
• v2 preview and stable release criteria are agreed.

Historical context

• #1934
• #1930
• #1976
• #2048
• #2202
• #2395
• #2463
• #2505