Inserting a layer in the middle of a stack requires unstack + link, which permanently drops merged PRs

Commencez par reproduire le comportement signalé de gh stack link et gh stack unstack, puis examinez la limitation de REST PATCH /repos/{o}/{r}/pulls/{n} et le flux existant de gestion de l’appartenance à la stack. Le travail est terminé lorsqu’une insertion au milieu de la stack ou une reconstruction sans perte préserve l’appartenance des PR fusionnées et conserve intact l’historique complet de la stack.

Summary

There is no way to insert a layer in the middle of an already-submitted stack while keeping the stack's merged PRs as members. The only working procedure (unstack + link) moves the still-open PRs into a new stack and leaves every merged PR behind in the old one, which is then closed. The historical grouping of the stack is lost, permanently and irreversibly.

Current behavior

Given a submitted stack S with, bottom to top, one merged PR #1 and open PRs #2 → #3 → #4, and the need to insert a new layer between #2 and #3:

1. gh stack modify is TUI-only, so it is unusable non-interactively (and it restructures the local stack, not the server-side membership of an existing PR).
2. Retargeting the base of an existing stacked PR is refused:
   • REST PATCH /repos/{o}/{r}/pulls/{n} → HTTP 422 … PullRequest.base is invalid
   • gh pr edit <n> --base <branch> → Cannot change the base branch because the pull request is part of a stack
3. gh stack link only appends to the top (gh stack link <stack#> <new>); it has no position/insert argument, and it rejects arguments that belong to a different stack.
4. So the only way out is gh stack unstack <S> + gh stack link <bottom> … <top>. unstack (v0.1.0) unstacks the open PRs and leaves the merged #1 in S; S becomes open: false with #1 as its sole member, and #1 cannot be linked into the new stack (rejected as belonging to another stack).

Net effect: a purely structural edit in the middle of the stack silently destroys the association between the merged layers and the layers that are still in flight.

Expected behavior

Either of:

• Insertion: a way to place a PR/branch at an arbitrary position of an existing stack, e.g. gh stack link --after <pr> / --before <pr> / --position <n>, without tearing the stack down.
• Lossless rebuild: allow merged PRs to be re-linked into a stack (or have unstack + link carry them over), so the recovery procedure above at least preserves the full history of the stack.

Why it matters

Merged layers are exactly the part of a stack that documents why the remaining layers look the way they do. Keeping them attached is useful today when reading the stack, and it is what would let the web UI group a whole line of work — landed and in flight — under a single stack. Today, any mid-stack restructuring resets that grouping, so long-lived stacks progressively lose their own history.

Environment

• gh stack version 0.1.0
• Private repository, stacks enabled.