I'm guilty of doing this in the past, but it seems like an anti-pattern because it attempts to create a local optimum, a big no-no in the Theory of Constraints[1]. Better to find ways to sustainably ease the constraint (code reviewers' time/attention) than to find ways to create more WIP at the constraint.
As someone coming down from a nearly 2 year fight with an engineering manager whose response to every bug was enforcing more code review rules, and every code review backlog was demanding more time allocated for code review, thank you for this comment.
i got a major cognitive dissonance from your comment because stacking PRs is for me the way to get more time and attention from potential reviewers by making their units of work smaller; hopefully small enough to be easily mergable. this is a case of 'more is less' (within reason).
I'm confused by your "major cognitive dissonance" comment.
What you describe appears to reduce variable costs (time spent reviewing) while increasing fixed costs (context-switching). That may increase code reviewer usage, but that doesn't necessarily increase system throughput or reduce WIP.
[1]: https://en.wikipedia.org/wiki/Theory_of_constraints