Thanks for the feedback, that’s interesting perspective, never thought about it in this way - actually, I agree with the definition of trunk-based flow as you described it. However, I don’t feel stacked PRs are strictly against it - I think it’s rather complementary to the methodology.
The whole point I wanted to make is how to stay productive if one has bigger changes in mind - definitely not something what’s happening to me often. But it’s super helpful to have easy way how to split a big PR into smaller ones without Git gymnastics and with auto tracking of its parent.
I believe the definition of trunk-based development presented is not aligned with the widespread one. Trunk-based development is a methodology where "everyone works in the main branch" and, if there are other branches, they are short-lived, i.e. less than a day.
That would render Stacked PRs as basically the opposite of trunk-based development, since to stack PRs, one assumes a single PR (and thus a branch), will live for several days because otherwise it would not be worth the overhead.
Have a look a this talk from MSFT: Git patterns and anti-patterns for successful developers : Build 2018