Nice to see some user testing of Picard and I am looking forward to the new improvements off the back of it. I do feel however you have a limited user case for it - individual files only. As we all know Picard works best (and always will) if we have albums/releases not individual tracks.
I would worry about dumbing down Picard too much (which is implied the way you are going with this) Cluster, scan and lookup do different functions and although the need more explanations. Combining into one (and not having the option of using the separately) can lead to many issues. Off the top of my head the problem of the “locked in” artist on a scan when it goes wrong. (now it is multi-artist it still can go wrong) e.g. a release that would be classed as “various artists” in MB if it is a few of the same artist on there the Cluster will hard lock it into that artist and never find the release on lookup.
We have know for years now many of this issues raised in this thread. (Scan button description/meaning, non useful tooltips and misleading Submit button, what do all the crazy array of icons mean, etc, etc)
For 2 panels I feel that is fairly common and mostly self explanatory (but as we know we still need to explain more with more descriptions and useful descriptions) it is going for your current file their tags (the left side) to the new/proposed tags.
Other major headaches for users of Picard.
a) Users adding tens (or hundreds) of thousands of files or more and expect it to magically sort them perfectly without any sort of interaction or effect on the part of the user. Education here is the key.
b) The eternal problem of users wanting their random track tagged to the album it came from and never see it from a compilation. (Sliders as we know are confusing and actually you cannot get them to give the desired outcome for this common scenario)
There are probably much better matching to be done in Picard (more details of comparing track length, etc) before it is ready for the much more automated way it is looking like going.