First of all, I like the change that sorts MB candidates above non-MB ones. Thanks for that -- this prioritization definitely seems like something we want to do in general.
Thinking about how to do this kind of thing more generally got me thinking about how the matching logic was originally designed and how we can keep it simple. Specifically, the matching logic gets a lot of simplicity out of segregating the core matching/ranking stuff from the distance components. Because all the comparison stuff is complicated and messy, it's really helpful to have it hidden behind a single abstraction: distance. This also lets us add on new distance components easily without affecting the core logic.
Every time we add new special cases to the ranking and recommendation logic, we break a little bit of this abstraction. That's fine, especially when it brings features that aren't possible otherwise (like the max_rec feature), but for the long-term health of that code, it behooves us to think in terms of distance as much as possible.
So what if we added in a distance penalty (configurable, of course) for matches from the Discogs plugin (and other plugins in the future)? This would have the effect of sorting the matches the way we want them.
The possibly negative side effect is that it might be confusing that a Discogs match that looks perfect will only have 99% similarity (or something like that). Two thoughts on that:
- Is this actually confusing? Maybe users won't mind since they'll understand that Discogs matches are penalized.
- We could rename "Similarity" in the UI to "Score". That helps explain why there might be penalties that don't really have anything to do with similarity.