In the general case, this is impossible while remaining meaningful. Suppose you have three commits, A (first version of the change), M (caused by a merge or rebase some time later) and B (updates to A).

If A makes changes to a file, M completely refactors that file, and B make changes with a similar effect (but different form) to the new version, we can not implement the proposed behavior in a way that make sense, no matter how clever we are -- the left and right sides of the diff would show completely different "unchanged" lines. Although a sophisticated reviewer might be able to puzzle through this, it would no doubt be very confusing to a novice. We currently do this only in cases where the reasoning is completely obvious (the lines differ only by whitespace changes).

What we can do is automatically update the revision with the merge or rebase commit (in addition to the actual change) when you update a diff, so you can view current vs state-after-merge using the UI. This is probably not even terribly difficult. It would look something like this:

+------+ +----------------------------------------------------------------+
|  xx  | |alincoln merged abcdef12345.                                    |
|  xx  | |alincoln updated this revision to Diff #12345.                  |
| xxxx | +----------------------------------------------------------------+
+------+ |Fixed feedback blah blah blah...                                |
         |                                                                |
         +----------------------------------------------------------------+

And then the table would be all like:

Diff 1                                x -
Merge                                 o o
Diff 2                                o x
                              [View Diff]