#21334 talks about not generating variables when we don't need to.
#21335 talks about not boxing when we store them

This issue is about being smart about what we store in variables.
Currently we utilize the ProjectionBindingExpression to store in variables while it is generally ok but there are some cases when a different strategy would actually achieve better perf.
Rather than dealing with ProjectionBindingExpression, we could deal with elements which needs to go into client code instead. In order words, we can take maximum subtree we can evaluate before going into client code and store that in variable instead.
One thing it would solve directly is (which has some overlap with #21334) condition ? EntityA : EntityB scneario where we could skip materializing one entity altogether based on how condition evaluates.
Places to identify what to materialize would generally include

• Top level if projecting a scalar or entity
• Members of NewExpression (recursive)
• Members of MemberInitExpression (basically DTOs) (recursive)
• Arguments being passed to client method or members.

The assumption that maximum subtree would be translated to server remains valid as long as no entities are involved. But with entities the server projection wouldn't be maximum subtree and we need to do that on client side.
A big perf here would be collections when both above entities have collection includes. We could skip materializing and populating whole collection if the entity is not materialized due to the condition. Collection won't be initialized so populate collection should no-op.

A caveat that if the same entity is being reference in multiple spots then we need to make sure we materializes only once. For tracking query it should do identity resolution but no tracking we don't want to create 2 instances.