[Debarati Roy Gupta] As a SM ,I would facilitate an open discussion with PO ,stakeholder and developers to see
1.Whether this change alligned to sprint goal.
2. Market criticality of the new request for upcoming release ,whether taking this request for this sprint really adding value to the customer.
3.Scrum team will be doing a risk assessment, based on the current capacity whether this can be achievable in the sprint.

Finally scrum team can decide based on the above factors whether the change can be accepted.
If as per the risk assessment Team feel it's not achievable in the sprint them ,we would request PO to prioritize it for upcoming sprint based market critically.
If it is alligned to sprint goal and as per risk assessment team sees it can be available in the same sprint them we may consider it with PO's consent.
Also coach the stakeholder that any change should be coming from PO as he is the value maximizer for the Product and " for Product Owners to succeed, the entire organization must respect their decisions ".

[Ajay Shukla] As a SM i will connect with PO and ask him whether this change is needed to give customer/stakeholder a business advantage? If yes then will go back to Scrum Team and discuss the same and if developers are ready to adapt then will be taken in current sprint. If business advantage answer is No then they need to wait till next sprint.

[Mohit Budhiraja] We need to first understand this change is important for key influencing stakeholder because of following possible reasons
1. External factors,
2. Evolving market conditions, or
3. Emerging opportunities
That is why he is reachcing out to us for this change to be included in ongoing sprint.

As per 2nd agile principle - welcome changing requirement , event late in development. Agile processes harness change for customer competitive advantage.  to address this situation Scrum team should come togather.
Scrum team following the above principle should come togather and discuss on possible below scenarios
1. If the team has capacity to pick this in mid sprint then lets go ahead with the change.
2. If lets suppose team do not have capacity to pick this then with mutual agreement of developers and product owner they need de-priortize any ongoing user story and pick this item on priority.

[Laxmi N] Mid sprint changes that have nothing to do with sprint goal but disturb the current sprint commitment are tough but not unheard. Initial understanding should be towards the business value and it's weightage, that can be calculated with wsjf or anything of the prioritization techniques set within the organization. And this request is to be met, it could be only under two conditions:

1. To use this incident for inspection and adaption together with the customer in order to understand why this happened and what can be done to avoid it in the future

2. Explain the customer the impact this kind of requests have to make sure they understand this is not to become a standard practice