Yeah the piece that "stacking" also really helps on is code-review. So When you have the "contextual" diff in the second PR you can get different stake-holders to review that one, while maybe not needing them on PR 1 for example.
It also allows you to stay unblocked the entire time you're waiting on these dependent PRs.
For "how they do it on github": the way we do it at Graphite (spoiler I work there), is that we make the unit of change a PR instead of a commit. ie. every PR has one small commit, and these get stacked on top of each other. The tool itself abstracts some of the complexity out of rebasing and managing all of these stacked PRs (which in the article are referred to as stacked diffs).
Does that make sense?