I think it depends upon your environment and how the product owner(s) react to missed deadlines. Because ultimately, changing the requirements increases the chances of missed deadlines.
Our job as programmers is to build what the business needs. So it's always appropriate to change the requirements of the user story based upon the business' needs. It's also appropriate to document the change(s) so that a postmortem review can identify those changes as a contributing factor.
The criteria to judge the change impact is the same criteria you use to estimate the user story in the first place. The developer working on that user story should understand the change and be able size the impact. If the new sizing increases the scope beyond the remainder of the sprint, then the modified user story should be broken down into smaller components. It's the same process that's used to size and manage user stories before they hit the product backlog.
So let's go back to the environment. If the product owner can't handle missed deadlines, then it's better to cancel the work from them sprint and re-schedule. That becomes part of the change management conversation. If the product owner is okay with some slippage, then the developer works as much into that sprint as feasible, and either creates a new story for the next sprint with the remaining work or lets the existing story bleed over. The new | bleed-over decision is one for the team based upon what works best for managing estimates.
But our job is to build what the business needs. Change is good. It keeps us employed. And it gets the business what they need.