I’m just getting my feet wet, and I notice a lot of recording merges where a higher MBID is being merged to a lower MBID even though the newer recording has better metadata (often, ISRC exists on the higher but not on the lower). There seems to be a script that ensures the high-to-low directionality.
I understand the rationale behind keeping the older recording. But if such a merge is accepted, is the (better) metadata from the newer MBID thrown away? Or are they merged?
I’m pretty sure that all the information gets merged. I’ve got this one open at the moment, which is probably the closest thing I’ve got to what you’re asking:
https://musicbrainz.org/edit/91384992
The YT links, etc will be added into the merged entry, if they don’t already exist.
Sometimes very old entities are merged into recent duplicates, making only this recent MBID visible and the old MBID disappear but all old data is kept (except MBID and disambiguation comments, see last paragraph)
So this case is why you can see recent MBID with more data than another older MBID.
About the loss of data when we merge recordings, you lose the disambiguation comments of the merged recordings.
But you can result fix that by editing the target recording with a pending edit (check the votable checkbox) at the same day as the merge edit.
I also try and take into account which is the most used MBID. If one recording has 30 releases associated, then that’s what I’ll use as a target. This database is linked to by many outside sources so it is good to keep the most use data.
Though, even in that case, all the MIBIDs from the merge are kept and become redirects.
The guidelines say “use the one with the best quality data”. The “merge to oldest” is one of those confused myths that exist. At lot of the time the oldest may be also be the best, but always better to check.
The MBID is not lost, it becomes a redirect, as @IvanDobsky said. Basically, if all else is the same then sure, merge into oldest if you can to avoid causing more redirects, but otherwise, merge into whatever is better and don’t worry about it. In fact, I’d argue rather than “oldest” we should then merge into “most used”, if we’re going to care (if a newer page for an artist has a ton more releases for example, then that MBID might be in use by more people).
Well for me the “this recording has more tracks and stuff” is something difficult (time consuming) or even impossible to prove when there are recent merge(s) of potentially old recording(s) merged into a 1 week old (young) duplicate recording MBID.
This MBID has no worth, in this case, it’s better to just take care of keeping the disambiguation comment, period.
But in comparison with this tedious or impossible process, checking row ID by script gives an instant relative age of all MBID in the merge. So I’m using that.
It’s also more fair to target existing ones than duplicates.
About the old MBID that redirect to the merged MBID, it’s true in most cases (browsing MB, web services) but not in all cases, like when the old MBID will never again be queried in third party DB like Flickr MBID machine tags (but it’s something that never really took off) or with the COLLECTION HIGHLIGHTER (but I hope it will be part of MB one day), among other things.
What @reosarevok says. He is a wise sage. (imagine a bowing disciple emoji)
One click on a recording and look at how many releases attached. It is not that time consuming. OR am I just mad in caring about stuff like that? 
It is also made easier by the scripts that flag up how many AcoustIDs attached. The more AcoustIDs, the more used it is.
Time consuming to check history for merges to see if the recording with many tracks and releases is not just a 1 week recent duplicate (merged wrong way), relatively more recent than another recording with only one track that may be 10 years old:
This is good to know. The same day that you file the merge, or the same day it is accepted and committed?
Thank you all for the thoughtful comments. Honestly in the sorts of stuff that I know anything about, there will be one recording that I personally call the canonical, that includes the release that first included the recording … and 5,000 later compilations that include it. In these situations the oldest and best are the same thing, unless people merged all the compilations and left the original behind, and that just doesn’t happen.
I was more looking at things I don’t know as well and trying to see how they work, and if the merge handles everything but the disambiguation, then there’s really little to go wrong when conscientious people file merges.
If you edit the merge target, you can do it when you want, before, after, it doesn’t matter.
Add long as it’s the target that you edit, not the source, it won’t fail.
I prefer doing it at the same time as the merge, with the make this edit votable option checked.
And I cross-link the merge edit and the target edit in both edit notes.
This way I can cancel both related edits if some reviewer find out that the merge is wrong.
Because if one edit is wrong, the other is usually wrong too.
Recent examples: