svn:mergeinfo Bloat After Subdirectory Merges in Subversion 1.8: Consolidate or Leave It?

Our repository has been on Subversion 1.5+ merge tracking for years, and repeated merges at the subdirectory level have left many files and folders carrying their own svn:mergeinfo properties. The project is now standardizing on the 1.8 client behavior, and I want to define a policy for handling this accumulated metadata going forward.

The concern is that scattered mergeinfo on child paths appears to complicate later merges and occasionally surfaces conflicts that seem unrelated to the actual changes being merged. At the same time, I understand that manually editing or deleting svn:mergeinfo can break merge tracking and produce inconsistent results, so I am hesitant to clean it up blindly. Assume a single repository with feature branches merged back into trunk, clients on 1.8 or later.

Does consolidating mergeinfo at the branch root (rather than leaving it on subdirectories) change the outcome of subsequent merges, or is it purely cosmetic? Is there a documented safe boundary for when elision happens automatically versus when manual intervention is required? Should a team policy forbid subtree merges entirely to prevent further bloat?