Will note that I'm not familiar with mailing lists. (I'm gen Z and have never touched this before) But looking through this, I have a few ideas, some for the AUR's side, others for the AUR helper's side, and some others that I'm not sure which side would need to contribute to implement it. I'll number these (1),(2),(3) in the order I said them for which side would probably need to work on.
(1) 1: My first thought was that for packages that are orphaned and are also EOL or otherwise dropped by upstream i.e. not the AUR publisher, but the developers. The PKGBUILDs should be made read only and unadoptable without confirmation of a fork or the upstream devs picking it back up. Seems extreme I know, but it seems a good amount of the packages that are orphaned there (that aren't git packages) are for packages that are EOL by the original devs or were for stuff that was since merged into mainline versions. (3) 2: as an addendum to idea 1, there needs to be an ability to redirect updates to the mainline package if a fork's features are added to the mainline packages. (2) 3: for the AUR helper's side, some malware analysis pre-step is needed. This could be as basic as a hook for utils like traur or some way to run yara/yara-X scripts on it (yes, I'm aware I or someone else could do that very quickly these days, but testing it might be iffy unless the all clear is given on the AUR's side when it comes to the malware stuff, that and there's no known steps on spinning up a custom AUR like repo it seems, but I'd imagine it's very basic.)
