It would more or less follow the principles of DIP-01 (a list managed by your WoT, which means distinct lists for distinct users) and DIP-02 (based on explicit attestations instead of scraped data). I can’t think of any existing feature of any existing client that does that. (Except for my WoT-generated relays list, sorta.)
Discussion
Ah, I see what you're saying. That does sound very valuable.
This, except mute list instead of relays. 
Tony’s comment made me realize that no, this would not actually satisfy DIP-02, because we’re scraping the filled list and inferring that follow == trust to help curate my mute list.
(Not sure if I’m linking to his comment correctly but we’ll see!)
nostr: note13fleh09v737x3r6ndg490f5at3frjf39zeyngl9w49hqw0afdkuq2734pm
https://damus.io/note13fleh09v737x3r6ndg490f5at3frjf39zeyngl9w49hqw0afdkuq2734pm
What's your understanding of the difference in meaning between a mute and a report event?
I’ve never used report event so I’m not sure. I guess it depends on who the event gets reported to and what gets done with it. Is it a developer-curated mute list that applies to everyone using that client? Or get passed along to relays and they use it to blacklist bad actors?
It's a public event, anyone can create and publish, and relays and clients are free to interpret how they see fit
I wouldn’t be surprised if relays are manually curating mute lists and using event reports to help them.
Centralized manual curation of something that yearns for decentralized curation. A losing proposition. Like in the last season of Halt and Catch Fire (they were trying to curate the web manually, pre-Google.)