Current idea for implementing this:

This not only shows all the formats, it also highlights the specifically found format. This both helps with identifying the proper release for cases where the CD might belong to just the single release or a box set with different media, but also helps identifying the release if there are specific subtypes of "CD" to be chosen from (like in your Copy Control example).

See code changes in pull request #2614 submitted by phw.

Really, all I mentioned was that even if a type is set to just CD a more specific type might still apply. This was more a side note, as I thought it being interesting in not relying too much on this when deciding whether to add a new release. No need to make a this a big argument.

No, you misunderstood. What I said [wa]s

No, it wasn't (see your own (initial) comment). Perhaps that's what you meant, though. I can only parse+interpret the text as presented. Clarity is the responsibility of the author.

a specific type like Copy Control CD, which requires quite close inspection and some knowledge how to identify

There's non-tiny labelling on both the front and back of the jewel case of the release in question, which includes the phrase “Copy Control”. Had Picard indicated that any of the likely matches were “Copy Control” (copy-obfuscated/DRM-infested) (especially when all the other releases were “CD”), then that would've made my (user) task of telling Picard to load that release, an obvious no-brainer. I would not have had to go delving into the database via the website.

Further/worse, having read a bit of the history around so-called Copy Control (read: copy-prevention/copy-obstruction), it seems that the publisher/distributor re-released the same album later, without DRM, due to public objection (and I imagine the Sony rootkit scandal didn't do them any favours). This later re-release was also listed in the release-group. Again, please see the links I cited.

Granted, it would've helped if there had been a Disambiguation string specified for otherwise similar releases (which is available within Picard, I noticed). As mentioned, I did some minor editing to remedy that.

It was the Annotations of the candidate-releases which helped distinguish (besides CCCD versus (redbook) CDDA) similar releases. This info (in the Annotation field) was actually trickier to confirm (eg, small details about what was (or was not) printed on the matrix of the disc).

Copy Control CD, which requires […] some knowledge how to identify

I'm not sure that there's a name for what I'm about to describe, so forgive my verbosity.

Think of bug-reports; insufficient information makes them useless. However, if a report is comprehensive (because a submitter is thorough) then excess info can be ignored by developers. Thus, the later is preferable over the former.

Similar idea; users are free to ignore fields which they don't understand (or care about), but users can't possibly be aware of fields which Picard is omitting entirely (even when they're highly relevant).

Hence one of my suggestions re making the columns/fields shown in Picard's DiscID results dialogue be user-configurable. Have the default omit medium-format. This at least allows some users to see more than the default set of fields (think of contributors wanting to verify DB entries against releases which they possess; I've already encountered several releases which seem to be either rare or unpopular, and have (for example) contributed DiscIDs). I'm aware that this (user-configurable fields/columns) would be more development work to implement, though (hence only a suggestion), but would resolve conflicts over too-much/too-little information for different user-groups (casual versus (dedicated-)contributors).

Besides, while I accept that most typical/normie users may not be able to easily identify sub-types of CD, I'm confident in my own ability to do so (else to learn how to), with a view to refining the DB. I realise that I'm an odd-duck, but it's likely such odd-ducks who contribute details which make the MB DB outstanding, useful, and likely unique. I'm thinking of the type of contributors who trawl through the DB for the likes of duplicates, and otherwise cleaning up the DB to maintain high-quality for everyone's benefit.

[CCCD] is likely not set for many releases where it would apply. So it should be used with care to detect whether a specific disc is already in MB or not.

I can quite imagine so, in other cases. But, that's a problem of data-quality in the DB, rather than Picard's problem. Picard should faithfully present the data which the MB DB returns (modularity for the win). If that data is inaccurate, then that's fixed by users noticing and correcting it (just as I did).
I'm concerned that multiple disparate (even if related) areas are being conflated, here. Else, I'm missing the point.

In this case (which seems most relevant/applicable to this ticket, I would think), (as far as I'm aware) the metadata which MB holds does seem to be accurate. For the release-group in question, there's only one CCCD entry. Later, seemingly-identical releases are not CCCD (but (redbook) CDDA) because the publisher/distributor had a moment of clarity/reason and offered non-DRM'd equivalents of the earlier CCCD'd-borked one.

[CCCD] is likely not set for many releases where it would apply. So it should be used with care

On this point, more specifically; while I don't dispute the likelihood of this point/observation, perhaps it's a result of (Picard-)users being unaware that the data is inaccurate.

I can imagine how it happens; if a contributor who doesn't have a copy before him, is adding releases to the DB (in order to be helpful), then he may not know (with enough certainty) to specify which sub-type of CD to specify for the medium format.
Perhaps that contributor is hoping that another contributor, who does have a copy of the release, will come along and confirm/refine the data, based on the various details of the disc and jewel case.

So, I suggest, as conjecture, that Picard currently omitting the medium format from DiscID results, is impeding efforts to refine the database, because (Picard-)users (who're much more likely to be matching via DiscID, because of having a copy of the release in their possession) remain unaware.

In my own case; I only learned of the differing medium formats, because I queried the release-group via the website, which does show that data-type.

So, if I'm understanding your implied point correctly (and if not, please do correct me), that the medium format specified in the MB DB isn't always as specific as it could be; well, presenting it in Picard, especially for users querying DiscID, and thus having a copy of a matching release, might then aid that effort by enabling/prompting the ones who care about data-quality to edit the DB to be more accurate.

If I had already known about CCCD (and other sub-types of CD), and Picard had made me aware that a release I was querying/matching-against was marked as a mere/generic “CD” (while the jewel case clearly said differently), then I would've made a point of going to the website to correct it.

Think of it in terms of usability/user-experience/interaction-design; enable discoverability, and reward exploration. Enable users of Picard to be more than passive users of the database, but to identify inaccuracies in order that they're corrected/refined.
That way, everyone benefits.

Part of my own motivation for editing, besides data-quality and experience (I'm an MB newbie, still), is to help other, future, Picard-users to avoid the same head-scratcher which I had to solve. Such as by populating the Disambiguation fields of similar/otherwise-identical releases.
Another factor which would help with that, is for Picard to present the medium-format (possibly conditionally; if any of the results are something other than m/^CD$/).

I didn't come to such conclusions lightly. While I'm new to MB, I have a technical background, and a fair bit of knowledge about usability/user-experience/interaction-design (hence my suggestions).

However, that all said; if there's some good reason to continue omitting the medium format from DiscID results in Picard, which isn't based on ‘the MB DB might be inaccurate’, then I'd welcome knowing it, to then possibly respond to it. I'll admit to (still) being a newbie to MB's technical considerations, and that there may well be something I'm missing (but, would appreciate learning).

Overall, having Picard present the medium-format (perhaps conditionally) doesn't seem like it'd involve much work (the API is likely already supplying that value/field to Picard, anyway), yet it would yield non-trivial benefits, both to users of Picard, and to the MB DB itself from some of those users contributing corrective edits to the metadata (from which everyone benefits).

Otherwise, if I'm missing something, here, then please do enlighten me.

No, you misunderstood. What I said is that a specific type like Copy Control CD, which requires quite close inspection and some knowledge how to identify, is likely not set for many releases where it would apply. So it should be used with care to detect whether a specific disc is already in MB or not.

[…] this feels a bit redundant, the variation of formats is really small.

Well, they're listed as separate releases in the MB DB. Thus, there must be enough of a distinction between them to warrant being separate entries.
I leave such matters to more experienced contributors.

I simply wanted to match against the release which I actually had, for which there were several barely-distinguishable (within Picard) releases.

[…] just because MB lists something only as CD it doesn't mean that the type shouldn't maybe be more specific, e.g. set to Copy Control CD or Enhanced CD. Those special variations are often hard to distingiush.

That's precisely my point (hence this ticket); the MB DB did have the relevant metadata (to unambiguously match the release which I had), it just wasn't presented in Picard.

Please inspect the various URLs/links I included, especially to the DiscID entry.

However, I can imagine why it's hidden by default, since the typical scenario will be matching CDs (as opposed to non-CD formats).

For Disc ID lookup it will always be some variation of audio CD format, otherwise there wouldn't be a CD disc ID. So this feels a bit redundant, the variation of formats is really small. But yes, could of course be added for consistency with other lookup results.

Just note that just because MB lists something only as CD it doesn't mean that the type shouldn't maybe be more specific, e.g. set to Copy Control CD or Enhanced CD. Those special variations are often hard to distingiush.