Haha, yeah hard to keep track of isn't it?
My initial response would be automatically to say that yes, order is significant. However that response is based around an assumption that on inspection of the code as per my edits is incorrect. Right now it seems to me that the only place order is being "respected" is in the part of the code that creates the XISBN pools - anything but your first result for a pool will be discarded.
I would have "thought" that priority should continue to play a part when it came to merging identifiers as well - as per my example above of the two results I am left with, one is my "excellent" match with a high quality cover and lots of good metadata, the other is a less quality match from having no cover (it could also be the case it has very little metadata as well). So as a user you would want the hyperlinked id's of ISBN/B&N/Goodreads or whatever in the book details panel to be going to your "best match", likewise if you did ctrl+d on it again to get fresh metadata it will now use the ISBN as a lookup so again you want your "best".
I never found this issue with my Goodreads plugin because I only return one result (well unless you enable the option to search multiple editions, but as that is slower I turned it off by default I tested it less).
Perhaps it is just a simple Kovid oversight, it is not often I have the confidence in my understanding of the code to call it officially as a bug
