Sprint review inspection

I'm guessing that you referring to this sentence from the 2020 revision of the Scrum Guide:

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.

This is compared to the equivalent sentence from the 2017 revision:

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product

Backlog if needed.

The words may have changed, but I don't really see a significant difference in intent.

Changing from "inspect the Increment" to "inspect the outcome" implies that you should be looking at more than just the product itself. The team should also be looking at the Sprint Goal, whether or not they met that goal, and how meeting (or not meeting) the Sprint Goal has impacted progress toward the Product Goal. I think these were all valid things to look at previously, but the new wording captures it better. The team producing (or failing to produce, in some cases) an Increment is only one outcome of a Sprint.

Even before the 2020 revision, looking at other aspects of the Sprint was always within the scope of the Sprint Review event. The 2017 Scrum Guide talks about the Development Team discussing what went well and what didn't go well over the course of the Sprint, reviewing the marketplace and budgets and schedules related to the product, and collaborating on what the various stakeholders believe to be the next best step to take.

The 2020 Scrum Guide does say that the team "presents the results of their work" to the stakeholders, so the team should actually review the Increment. Since the Sprint Review is not a gate to releasing the Increment, the Increment reviewed would be the most recent Increment produced. Looking at KPIs or other forms of feedback would also be within the scope of the Sprint Review, especially if it would be helpful to make changes to the Product Backlog and inform the participants on the next best step to take.

I see in new SG that during sprint review outcome (not increment) is inspected

The Scrum Guide says:

Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.

Hence the outcome can be more than one increment; multiple increments may have been released, all of which yielded inspectable outcomes.

IMHO It is worth checking differences between result vs outcome, below are some examples as I understand them after some reading:

• The result implies direct causation of something, for example:
  • you focus on adding 3rd party sign-in possibilities to your product, and as a result, you have Increment with "Sign with Google" added.
  • The man jumped from the roof, which resulted in his death.
  • Three is a result of my dice roll.
• The outcome, on the other hand, is something broader, causation is not so straightforward and invites some possibilities to the mix, for example:
  • As we added the "Sign with Google" option, we see an outcome in improved form conversion rate and users NPS.
  • The man became depressed after he lost his job and turned to drink. His alcoholism eventually destroyed his family, making him more depressed and without hope. The sad outcome of all of this was his suicide.
  • Three is one possible outcome of a dice roll.
    • You will know if it results in that outcome only after the roll.

With that in mind, I would say that 2017SG was more result-oriented, and the current 2020SG strives to be rather outcome-oriented because Increment is a result of work within the Sprint and this leads to an outcome that is not and should not be narrowed only to the Increment.

Here is a made up a scenario that may be helpful:

• Our Product Goal is to integrate with commonly used one-click 3rd party solutions, and in that context, our Sprint Goal was to add 3rd party sign-in option. The Increments that we create resulted in "Sign with Google" and "Sign with Facebook" options. As we expected as an outcome to improve the conversion rate of the sign-in form, that is not the only outcome of the Sprint. While more people sign in, it turns out that our infrastructure is insufficient to deal with such a traffic increase, because of that we encounter an even higher churn rate, so the user base grows at a similar pace as before the Sprint, and our NPS dropped by 20 points.

Should I actually think that a sprint review is now to inspect outcome AND to inspect product increment? As product increment itself is not outcome itself ? So for instance during sprint review scrum team and stakeholders may inspect kpis relaled to increments released during sprint (how number of customers increased etc.) AND then inspect all product increments together that were done during the sprint?

I think I may be wrong. Maybe I should think that sprint goal describe desired outcome and inspecting outcome is actually insecting product increment but from the perspective of sprint goal instead of all pbis done? 

In my opinion your last statement is the right way to view it.  Did you achieve the outcome you wanted? (Sprint Goal)  Is there anything that you can show the stakeholders to support that achievement? (Increment)  Is there feedback that can help the team move towards the next goal? (Input for Product Backlog).