I was thinking about this on the way into work, and there are two main chunks of Gnus functionality I'd like to see incorporated into Scoop: adative scoring and GroupLens functionality. First I'll explain briefly what scoring is:
Scoring is Gnus' alternative to killfiles. Rather than simply choosing not to see posts from a particular sender, you can add factors that cumulatively decide whether or not you see the post. Example chunks of Lisp define what you can use to modify an article's score, but the machanism is easily extended. Typical score files punish very short articles, punish authors that the user has chosen to punish, remove points from articles with subject lines containing no lower-case letters, reward articles replying to one of your own posts, etc. etc. This can become as complex as you want it to be.
So that's scoring. Now for the really nifty bits of Gnus functionality that I'd like to see in Scoop:
Where does the adaptive come in? Well, as you read articles you can tell Gnus how much you enjoyed the article. This can be used to add weights to the subject line of the article, the author, and other metrics of the article. This means that Gnus adaptively learns what you like in an article, and conversely what you don't like. Articles or threads can be sorted by score, and/or below a certain score an article can be marked as read, on the assumption that because you didn't like reading its close neighbours in article space you won't like reading this one.
There are a lot of bells and whistles surrounding the implementation of this (automatically expiring entries, so as not to clutter score files with information regarding long-dead threads, etc.), but that is the basic principle. There is more information in the Gnus manual.
GroupLens is scoring taken to the next level. It works on the principle that if you have a large group of people, all of whom are generating article scores (based, for example, on the adaptive scoring described above), these people can be clustered. By this I mean that groups of people with similar tastes can be identified and their recommendations can be pooled; if someone that has in the past made similar choices to you recommends against a new article, the article will drop down your priority list. For this to work requires rather wide participation, in order that suitable fairly stable clusters of like-minded people can form, but it can do an excellent job of winnowing the wheat from the chaff.
It struck me that this kind of meta-rating system might make an interesting addition to Kuro5hin (ie to Scoop). Advogato's experimental approach at community building might also be an interesting place to test this.
Of course, with an NNTP Scoop back end it would be possible to use Gnus to obtain this functionality, but if the system was implemented in Scoop it could be propagated through to News quite straightforwardly (eg by adding a X-Score: header) and would likely have much wider takeup.
The final thing I'd like to say on this is that for me one of the great pleasures of using Gnus is the wealth of customisation that is possible. This is partly because it's written in Lisp, and so customisation of the code is straightfoward, and also because the author seems to have ensured that everything that it makes sense to configure has a customise variable bound to it. This allows fairly massive customisation in a pointy-clicky fashion, without having to see any scary Lisp code. If Gnus-style scoring is to be a success, I think it would need something approaching this level of configurability.