@isidorn Please take a look. I went with two separate objects strategy, as you were suggesting. Thank you!

@dgozman nice work, I really like it.
However I would prefer if we clean this up a bit. For example I feel like we are abusing the Expression class here since we only use the value. And we introduced an issue since the toString is now not correct in the Watch Expression view since the Expression is also used there.

Due to that I suggest the following:

1. Move all the REPL specific classes from debugModel.ts to replModel.ts (SimpleReplElement, EvaluationReplElement, RawObjectReplElement)
2. Instead of reusing the Expression class I suggest we introduce a new class which will live in replModel.ts and extend ExpressionContainer and will only be used in repl. It will not have the unneded stuff from Expression, and the expression.evaluate can be moved to a helper method that both of these can use
3. We get rid of stale css class names output.expression both in repl.css and repl.ts and we use our new names.

This new class and the EvaluationReplElement are pairs. Due to that we should give them nice name. Here are some ideas and I am open to suggestions:

• ReplEvaluationInput and ReplEvaluationOutput
• ReplEvaluationExpression and ReplEvaluationResult
• ReplEvaluationInput and ReplEvaluationResult (might be my favorite combination)

Let me know what you think. Thanks a lot!

@isidorn Thank you for detailed feedback! I followed your suggestions, please take another look.

• Went with ReplEvaluationInput and ReplEvaluationResult.
• Moved code to replModel.ts.
• Removed .input.expression, .output.expression and .input-output-pair from repl evaluations. We still need .expression, to pickup styling from renderExpressionValue. Also, there are still .output.expression left in other repl elements, which I'd like to not touch here. Is that ok?

This looks great, thanks a lot!
I have left some comments inline in the code. Can you please tackle those and then we can merge this in? Apart from that:

• Can you please merge with latest from master and resolve conflicts? There is one simple conflict in debugSession.ts
• You did changes in the getHeight method and they make sense, however can you please test that the REPL scroll position behaves as expected when new output comes. Here's an example of a bug Scrolling in debug window is behaving strange since 1.33.0 #71737 which we can potentially break by changing the getHeight
• Did you run the smoke test so we verify we did not break anything with the css names? Here's how to run it https://github.com/Microsoft/vscode/blob/master/test/smoke/README.md
• Is it possible to write a unit test that captures these new behavior so we are sure we do not break it in the future? Adding an element immediatly adds it to the repl, and once it is evaluated we check there is an additional element?
• Not touching .output.expression makes sense, that is not directly related to this PR.

Thanks again!

Great work, I like that we moved those attributes up to IExpressionContainer.
As for the unit test to test the whole debug session flow - we do not have. Since that would require a real connection to the adapter, and spawing processes which felt liek out of scope for unit tests. Though we should probably invest in writing some integration tests for debugging.

I also tried out your changes and tehy look awesome to me. Merging in. Thanks!