It's possible you're tackling a symptom and not the root cause?
Do you have User Stories* and are they managed in some tool?
Do you have acceptance criteria for each User Story?
Do you formalize the acceptance criteria as Test Cases?
Do you "link" each automated test to its corresponding Test Case?
If you can answer Yes to all questions then all you need to do is to manage your User Stories and Test Cases. It's very unlikely a test case will fall into two different User Stories, and if it does there might be a valid reason for it.
Additionally, tools for handling User Stories and Test Cases are usually much more prepared to handle this information so you should be able to query for duplicates, etc., very easily.
If you answer No to some of the questions then I'd say that's the root cause of your problem.
Additional benefits of this approach:
- The chances that you're testing something that's not important are greatly reduced because you only test what the Product Owner and team decided was important.
- Documentation of the automated tests in the code is now just about including some link to the Test Case.
- Any business person can easily review your Test Cases and deprecate/improve them.
*You can replace User Story with requirement or something else if you're not using an Agile process.