I had originally thought that the bundle hits would be scored so that the first hit in the bundle would get the "normal" score and the next hits in the bundle would get a significantly lower score, so that in the typical case their score would drop at least one "star" ranking. Considering a typical user browsing at * * *, this would be all right if the first hit was scored * * * and the others * *, but if the score of the first hit was * * * *, then the others hits might be * * *, bringing again "clutter" to the user browsing at * * *.
A bigger problem with the decreasing scores within a bundle is if any of those hits become a triple in the future. It can't be so that the score of that triple would depend on the position of the note in the first bundle. It kind of works now in the current setup, where the moderated hit in a bundle loses its moderation the moment it becomes a triple.
So, this brings us a new design goal -- all the hits in a bundle (or generally speaking, a group of hits) should have the same score. This in turn means that we'll need to bring in support for the grouping of hits. In practical terms this would mean the hit list would be modified to show "100 x

" in case of such a group hit. The hit report page would then show a list of all the notes in the group (or a summary of them), showing that these 100 x

travelled from place 1 to place 2. We could have a rather strict criteria for forming these groups, such as all hits having the same denomination, all entered at the same locations at roughly same times by the same users. If there are big enough differences, the other hits could end up in a different group.
We could also take this grouping into account when determining how often users get hits with each other. I'd say that if someone gets a 100 x

bundle from a bank that was dropped there by some other tracker, it should count as "one occurrence" when determining the hit frequencies. There are also people who would then say that this group of hits would actually count as one hit (approximately like it's now), but given the recent feedback about this I'd be inclined to count all those hits within a group as hits.
There are a lot of hairy implementation details for this scheme, which I've not described yet. Perhaps I'll do so at some later point if needed.