1. If you edit A after reviewer comments, B will now have a dangling source. You'll need some rebase-fu to handle that, and the pain is significant if the chain is long. In stacked-diff workflow, it is handled automatically.
2. If you need to insert a new PR between A and B, or swap the order of some PRs in the chain, you'll need to manually do a lot of rebase-fu, and possibly manually updating the "target branch" on github. While in a stacked-diff workflow, all of these are handled automatically.
> 1. … You'll need some rebase-fu to handle that, and the pain is significant if the chain is long.
`git rebase --update-refs` on the last branch will handle updating of all the intermediate branches in the stack, you just need to force-push them all at the end.
It does help with 2. as well, but you will indeed need to manually update the target branch of a single PR on GitHub.
Open PR A-->main, while it's getting reviewed (or maybe it's in WIP state for some reason), create a branch B off A, and eventually open PR B-->A. Now, you never actually merge B-->A, it's only there so that the PR can be reviewed and diff can be seen. Can be repeated as needed.
In fact, IIRC, in the example above, if you merge PR A, GitHub will switch PR B's target branch to whatever A was merged to (in this case, main).