"That's the thing about zombies. They don't adapt and they don't think." - Max Brooks
One of the earliest challenges I ever had to resolve, as a Scrum Master, was the proper disposal of the dead. The typical situation ran as follows. My team would plan user stories into their Sprint Backlog, and would then work on them during the Sprint. The corresponding value would be invested into the increment. In other words, an increment of release quality would be created, such as would meet the team's Definition of Done, and those planned stories would then be removed from the scope of remaining work.
The problem was that occasionally, as a result of experiences gained by incremental release, some of those stories would be found to be incorrect or otherwise inadequate. This is, of course, entirely to be expected from an agile way-of-working. Each release is an opportunity to inspect and adapt the product. However, it can also create a problem - or at least the perception of one - for a team which has consigned the associated user stories to history. How can those stories then be revised to properly capture the latest understanding, so further work can be done and the product improved? This was the quandary my team found itself in, and they looked to me for a remedy. In short, they wanted me to bring their user stories back from the grave.
What they didn't quite understand, at that point, is that user stories are only "valid" for the Sprint they are developed in. Remember that a user story is a placeholder for conversations about a possible requirement. Those conversations happen during a Sprint in which the story is actioned. Once the time-box is over and the stories retired, the conversation placeholders within it are indeed history.
If a story is found to be "in error" after it has been retired - even if it is just one or two different acceptance criteria which have been identified - then those findings relate to a new story. In other words, we will have a new placeholder for one or more future conversations about the required scope, and the work for this must be estimated and accounted for on the Product Backlog. The new user story might resemble an earlier such placeholder very closely, but it will be a new story nonetheless.
Of course, if the acceptance criteria of the original story were not actually met, then the story was never completed in the first place. It should remain on the Product Backlog with a re-estimate of the work needed to finish it.
Sometimes people can tie themselves in knots about user stories "breaking" when new requirements emerge. The thing to remember is that a user story can't actually break. The conversations will hopefully happen, and the story will either meet its acceptance criteria and satisfy the Definition of Done by the end of the time-box, or it won't. The conversations the story represented during the Sprint cannot break as a result of any future discovery, and so the placeholder itself can't break. None of these old conversations can travel forward out of the past and into a future time-box where they become undone and broken. What will "break" - hopefully - are certain products of that story, such as deprecated regression tests derived from old acceptance criteria.
It's entirely reasonable to suppose that acceptance tests will need to change - just as the system itself needs to change - to accommodate new conversations and new stories that emerge as a result of agile development and delivery. It would not be reasonable, however, to "consider the impact" on old stories. There is no impact. There may be an impact on their products, such as BDD tests that circumscribe old acceptance criteria, but this should be addressed by new stories that consider the system as-is and the work remaining. That is achieved by having new conversations and new stories to represent them.
Old stories are over with, spent, archived off, in the past, and finished. Move on. So don't be tempted to bring a dead story back from the grave - create a new one instead. Happy Halloween!