I don't think there is any way to automate something like this currently.
Right. In particular, no kind of 'fuzzy logic' is going to associate Abyssinians, Vectors and Michael G.
This may be a case where it would be more productive to examine the question carefully before expecting any answers. It's important to first be very clear about what you want. That's easier said than done when dealing with something as flexible as MC. But there is something fundamental that needs to be decided first...
In the context of a collection of files naturally organized by Artist and Album, what, exactly, is an Artist? Using your example, I suspect you're happy thinking of that list as one Artist—
The Abyssinians. Or maybe two, if you consider
The Vectors is really a completely separate band. Or maybe three, if it really was
The Abyssinians and Michael G. (as in a collaboration substantially different than either of it's participants) rather than
with or
featuring. My point is, there is unlikely any right choice in these matters. You have to make the one that makes the most sense to you. And accept that may change. For example,
The Vectors is just an "early incarnation of band"—until you discover, say, they recorded 6 albums more in a rocksteady than roots style. Then you may wish to recognize them as a completely separate Artist (and probably use some other method of associating the two).
Having some very specific idea of 'Artist' in mind is helpful because so does the design, logic and features of the program—when it comes to handling the association of Artist and Album. It will group any way you like (as I suggested before), but I would recommend sticking with the standard provided if at all possible. Now that [Artist] can be a list, it's more flexible in supporting different ideas of 'Artist'. But bear in mind you don't have to do that. Your decision as to what an 'Artist' is may be driven more by the preference that albums be listed only once under one Artist. KISS. Which leads to the next consideration...
However you define 'Artist' and choose to group albums, you'll want other means for associating other artist names, individuals or other entities with the same Artist, Album or Track. In doing so, it will be much more effective to assume you may want to do
anything with the data, not just something in mind now. The data will therefore be more useful the more specific it's definition. In other words, use separate, clearly defined fields for AKA (perhaps including misspellings), Band, Members, Featuring, Related, etc. Whatever fields you decide on will depend on what makes sense to you and your collection, and available data sources. Use Artist- and Album-related fields wherever possible. Not only is that easier, it helps keep the meaning of a field specific and consistent. (Beware, however, Artist-related fields will only be related to the primary (first) artist.)
Having such fields—and confidence in the data—it's easy to use them alone or together (using an expression) in a view. For example, use ListBuild() to define a pane or category with a combined list of Artist, AKA, Band, Members, Featuring and Related, and use that to locate files with any one of those terms. In a pane, that has another equally useful function—displaying names associated with the selected files (e.g., members of the group). Those, in turn, can be selected to view other albums the term is associated with. This provides an effective means for browsing the collection without having to rely solely on the chosen meaning for 'Artist' and the related grouping.
For me, using single (and only rarely multiple) Artists works best. That way, I'm not confused by whatever appears in a view. If it's unexpected, I generally know it likely because I don't fully understand what a particular pane selection is doing. (I do have some complicated ones that take time to troubleshoot and learn.) I'd much prefer any complexity in my library be concentrated in a handful of expressions—even if some of them can make my head explode—rather than in poorly defined fields (of which there could be many) in many thousands of records.