In Scrum, all of the requirements (and all other changes needed to the product) are maintained in the Product Backlog. The Product Owner is ultimately responsible for the content and ordering of the Product Backlog. The Scrum Guide is light on guidance for multiple teams, but there are lightweight scaled Scrum frameworks such as Nexus (from Ken Schwaber and Scrum.org), Scrum@Scale (from Jeff Sutherland and Scrum, Inc.), and Large-Scale Scrum from Craig Larman and Bas Vodde). There are commonalities among these scaled frameworks - a single Product Backlog for all teams working on a single product and a single Product Owner who is ultimately responsible for this Product Backlog.
Regardless of the process or framework used, redundant requirements would be identified during the refinement of the Product Backlog. Ideally, the Product Owner and anyone supporting the Product Owner would be able to identify the redundant requirements before they are even added, but the refinement should be when the team identifies the redundant requirements.
In a complex system and for distributed teams, I'd recommend a tool for managing the Product Backlogs. This tool should allow for searching and other methods of categorizing items (such as tagging and labeling). This should improve the ability of the Product Owner and the people supporting the Product Owner to search both done and planned work to see if there are related or conflicting requirements.
The knowledge of the various development teams can also be used, but this is harder with both multiple teams and distributed teams, who may not have complete and in-depth knowledge of the entire system. The bulk of the work to manage the product and all of the requirements falls to the Product Owner and any product managers, analysts, or others supporting the Product Owner.
Regardless of who finds the conflicting requirements - the development teams, the product management staff, the Product Owner - the resolution is typically done through conversation, with the Product Owner having the final decision as to the Product Backlog and therefore the correct requirements for the product.
Scrum, or any of the scaled Scrum frameworks, doesn't call for any special handling of any conflicting requirements. There is no need to assign IDs to or do anything special.