Almost All Recordings in Musicbrainz are for Merging!

[The_Incredible_Boom_Boom]

So if I get you correctly you would have a single entity for the recording, but therer would be different mixes or variations of this recording. Things like mixing relationships, ISRCs and AcoustID would be linked to variations, as would be the tracks of a release. So it basically boils down to what I already wrote above, that your suggestions leads to another layer.

Yes, but it’s not “another layer,” because the information is already present in the database.
The problem is primarily one of display on the front-end and JOINing on the back-end.
For the eighteenth time, the relationship between Release Groups and Releases is handled in an excellent manner, but Recordings taken in a completely opposite direction.

Release Group → Release
“Recording Group” → Recording

KISS.

@outsidecontext

What I don’t get is how this helps with the original concerns of this discussion? The schema would get more complicated, editors would still need to identify either the exact mix or they would add a new mix. They also would need to identify exactly on what recording this mix is based on. If they couldn’t say for sure, they probably would need to add a new recording and a new mix.

The only reason you don’t see the unnecessary bloat and complication now is because you’re used to it.
If you venture to most any music collection circle online and there is a thread or topic about MusicBrainz, you will assuredly discover a lot of people cannot wrap their brains around things like the fact songs are considered distinct and separate simply because of something like two “Yeah” ad libs in-between choruses.

Here’s (what should be) a “Recording Group”. On the back-end, all the variations of this song are already joined together. Visually, headers can used to group the track variation that appears on a various compilation and the one that appears on the original album, from this random “radio edit” released 2016, but currently shares no - zero - none - nada - relationship with the original recording in any tagging program and is hella confusing for many non-MetaBrainz insider club members on the website.

The vast majority of people tagging from the database through Picard, MP3TAG, beets and whatever simply want there to be an actual relationship between “Say My Name” from 2006’s “Live in Atlanta” release and “Say My Name (Timbaland remix)”, by way of the original song.

@aerozol

It seems to me everything you want merged would already be merged at that level? So what’s the point of not allowing the granularity at the recording level?

For starters, not every track in the database is linked to a work.
EDIT: 1st a., but since all “recordings” in the database must have a “recording” entry, this would ensure persistent relationships among each “recording” entered into the database.
Next, adding work relationships after entries and is likely beyond the patience and time commitment of most editors.
Third, tagging programs using the database are not able to link individual track information based on the WORK ID.
Fourth, see above with the “Say My Name” example. The already-present-in-the-database information is what needs to be used to leverage the relationships among what @jesus2099 (correctly recognizes as confusing to casual taggers and) labels “MB recordings.” Not adding more fields and more lines to the schema.
Fifth, the granularity won’t go anywhere. It would just be consolidated using a less cliquey, insider-catered to format.