A RatingGroup filtering system would have many "rating groups". Each rating group comes up with ratings for content in whatever way they want; they can vote, they can come to a consensus, they can use an automated method. Users can "subscribe" to various rating groups to access their ratings. Users can then use these ratings to filter their content.
It should be noted that the presence/absence of a page on RecentChanges can be thought of as a binary rating. So, a special case of RatingGroups is a number of groups, each of which produce a custom-filtered RecentChanges. A user could subscribe to a number of these groups, treating them as "overlays" -- i.e. the user could start with nothing, and then choose to see only changes which are syndicated by a RatingGroup to which he subscribes, or a user could start with all changes, and then SUBTRACT the changes listed by some groups.
For example, using the additive filtering, you could subscribe to the "TourBus" group and the "OneBigWiki" group and see ONLY changes which are on either the TourBus pages or the OneBigWiki pages. Or, using the subtractive filtering, you could subscribe to the "no TourBus" group and the "no OneBigWiki" group and see every change except for changes on the TourBus pages or the OneBigWiki pages. Of course, you should be able to mix the two also (start with nothing, add TourBus changes, and then subtract OneBigWiki changes, for example).
A more difficult to implement example; you could subscribe to "Bayle's picks" and see only changes which have been flagged as interesting by me. The difference is that in this example, I explicitly rated each Change that the group syndicates. In the previous examples, the groups explicity rated pages rather than individual Changes.
We may as well make filtering more like PageClusters. Have an option so that if ANY pages are filtered by the filter, instead of showing nothing, show a note like "some TourBus pages were filtered". You could click on the notification to get a list of all the TourBus changes.
For the simplest part, all you have to do is to add an option to action=rc (the option treated like show minor edits, etc) which specifies a negative filter control page (i.e. "action=rc&filter=NoTourBusControlPage???"). Now, NoTourBusControlPage?? is just a list of page names, separated by whitespace. This list is parsed into a Perl list. During RC generation, each time a Change is about to be added to the page, the page name is checked against the filter list, and ignored if it isn't there.
Multiple "&filter=" options would also be scanned and would just be added to the end of the Perl filter list (you don't even have to prune duplicates).
now, just like Preferences allows users to have in effect a &showedit=0 appended to their RecentChanges requests, use the same mechanism to allows them to in effect append an &filter=NoTourBusControlPage??? (or whatever page they specify).
note that this simple filtering is scalable to more complex stuff later.