I agree this is ultimately because github has a real problem in their user interface, that the knowledge of the destination branch for a merged PR are dumped rather than preserved in the PR records. This leaves us with a choice between several (IMHO) unpleasant alternatives - struggling with multi-commit PRs as we do now, only one commit per PR, or merge commits. Which is the least worst?
I'm basically OK with the one commit per PR, except that I've had simple PRs hang out for a month or so without review or comment, so something like #4029 could take half a year to get in, and that's just one piece of a larger work. That's kind of painful. There's also the problem that I get negative feedback for PRs that don't have an immediate and obvious use. That's problematic if the usage is 2 or 3 PRs in the future, or like #4029 where the final commit that ties all the pieces together is 7 commits down. Overall, I would tend toward keeping rebase merges for PRs with 1 commit and using merge commits for multi-commit PRs. The counter argument is this is too complex a procedure for our community.
