Let's assume that the result of the evaluation appears in the Variables window, as by enabling the "purple diamond" button.

Expression evaluation currently behaves in two ways:
1) If you write a single expression, it gets evaluated and shown. Statement expressions also belong to this category.
2) If you write a semicolon-separated list of statements [note 1], local variable declarations included, they are executed as if they were a piece of code and the result of the LAST statement is shown.

The second point has two limitations:
A) If you want to evaluate an expression "e" after the statements and their side-effects, you cannot write [note 2]
    stmt1; ...; stmtN; e
because "e" is not a statement, so you are forced to write a final fake statement like
    stmt1; ...; stmtN; Object o = e
which of course is quite annoying.
B) Instead of presenting the execution of the whole bunch of statements in an aggregate entry, each statement could be shown as a single entry which shows the value of the underlying expression/declaration. [note 3]

Notes:
[1] A semicolon-separated list of statements, modulo syntax errors as per bug 190904. What really counts is the parsed AST, so something like
    method1() method2()
seems actually count as a semicolon-separated list of statements.
[2] There are many differences in the behavior of the evaluator whether "e" is followed by a semicolon or not, and whether all of the statements are expression statements.
[3] When some of the statements is a control structure (block, if, loop, switch, ...), the "unwinding" can become extremely hard, so maybe cases containing these particolar statements can be ignored. Indeed, IMHO one rarely wants to evaluate complex snippets.