Conflict markers don't merit being included in the permanent history of a project, and they break the build and prevent using tools like bisect. As a dev, I'd rather pull the conflicting changes and resolve and test them in my workspace than have to rewrite history to get rid of invalid commits. My branch isn't ready to be reviewed and pulled unless it's up to date w.r.t. master.

And the master branch (the starting point for new feature branches) should contain the code that's already released and vetted in production, not whatever you hope to release.

I would find this incredibly annoying in the context of a code review if it was the only diff view available.

When performing a code review, I like to understand what changed on the branch from merge base. The "tripe dot" diff is perfect for this because I don't want to have to think about the new commits on master. That would make the pull request diff appear different on every commit to master. This would be like a constantly shifting kaleidoscope and would make it difficult to maintain a fixed frame of reference during the review.

When assessing whether the code is good to merge, I also like to know how much work there is left to do to integrate the changes back to master. And Bitbucket's "phantom merge" is certainly useful in this regard.

But most of the time as a reviewer I want to see the "triple dot" view on the pull request.