I am still digesting all of the comment here, all good stuff I think. But I wanted to comment now only on the audio formats. I agree there will be some difficulties there, especially since there is a wide range of knowledge levels, and that the normal user needs to be assumed to be mostly ignorant, which is not meant to be insulting at all, just that many people just dont care, as others have pointed out.
While this is generally correct, it is not always correct. Lossless means it is a lossless file in comparison to its source. Typically, lossless means it to be comparable to a 16 bit 44.1 kHz source, like a CD. In this description, it is correct, a lossless file of 16 bit and 44.1 can basically be converted between formats without any issues. But if you have a 24 bit FLAC, and convert that to a 16 bit FLAC or any other 16 bit lossless, you cannot go back to the 24 bit. This also applies if you take a 48kHz or 96kHz to a 44.1kHz, once you have created loss, you cannot undo that. 16 bit and 24 bit are just higher levels of the norms for lossy like 256, 128 and 320 Kbps, 16 bit and higher just come in higher at 700+ Kbps.
Currently, MB does this by default. CDs have a standard of 16 bit 44.1kHz. This is actually tracked in MB in the medium format, for example CD vs HDCD, etc. Vinyl and cassette also have their standards making the quality differences all ingenant. The same could be done for digital, there are just different medium formats we could use vs just calling everything “digital media”. So if I see CD as a format, I know the quality, and if I see vinyl or cassette, I also know the quality and know that the CD falls in between them in quality.
Now this all assumes that the vendor is trustworthy, as others have pointed out. This is a common issue, and many do not even know if they are being lied to or not. Even CDs have been known to have been made and released from MP3s, which is nowhere near CD quality audio. There are many ways to tell this, but I do not know that going into that is beneficial now as just talking about quality and containers (file types) is causing enough damage.
On what to take into consideration for a release, I do not believe that if I have a CD and RIP it to MP3 files that it is a release. The CD is, my RIP is not. No different than if I copy a CD, that is not a release, just a copy of the release. The thing is that converting a PCM file (lossless types) to a compressed audio file like MP3 or M4A is similar to a mastering process. In mastering, you cannot master a master. Meaning that once mastering steps have been taken, mastering it again creates more loss, generation loss. So the source is a major factor in all of this and relied greatly on the encoder, encoder settings and encoding process. For example, if I take a 24 bit FLAC and use my nifty GUI sound converter to make an MP3, that could result in a total mess. What is happening to those top 8 bits for example? The encoder most times does all of this with default settings so the user does not need to have knowledge of anything, and that works great because most will use it and if it plays, they are a satisfied customer. But for our purposes, what does my MP3 have anything to do with a release? It is no different than me trying to add the disc ID of my mixtape, that is not a release. My MP3 will be different than your MP3, different if I change encoders, and even different than a M4A conversion I make from the same sources.
Lastly, on tagging digital files, as pointed out very well here, there are issues. This is one main reason I do not tag my files with Picard anymore. The original meta data tells me more about the digital release than MB can. If I tag in MB, my actual release date is overwritten by the date in MB for example. Although some find release date not important, it can be real important, especially on releases that are initially released, then re-released (different date) with the same title and track list NAMES, but on close look, one of the tracks is actually different but titled the same. Yes, this does happen and is a real thing. On the meta data side of this, the only way I can identify this on original metadata, using iTunes as an example, is via the release name + release date, or by the iTunes IDs. The tracks that differ will be clear from the different ISRC assigned in the meta data. So in this case, not using ar elease data just makes it more likely to mix up the releases. So me, I want that release date as is, not changed to what MB accepts as correct via tagging, but I want it to be correctly representing the release I have.