Changeability is a quality attribute of requirements that is emphasized in some classic literature. To get changeability of requirements, they must not be redundant.
However, when dealing with requirements in Scrum, some practices will inevitably lead to redundant user stories. For example, if a software shall have a number features that are similar from a technical perspective, but the user has a different path in the UI for each feature: In order to keep the stories small (INVEST), I would create different stories which are only slightly different, or possibly even equal only with different acceptance criteria. Now, when the business requirement changes, I have to make sure to update all redundant stories accordingly.
Normally, this would be manageable. After all, there should not be a large number of open stories, but just enough to fill a small number of upcoming sprints. In practice ("Scrum, but..."), customers may insist on a breakdown of a large number of requirements for planability. But also large-scale Scrum may lead to a situation where there are a lot of open stories.
Can a long list of open stories be managed without losing the benefits of Scrum?