It would be fine to see values coming from MusicBrainz in the Metadata Pane.
If you load files into Picard and get data from MusicBrainz you have both, the tag values from the local files and the values from MusicBrainz. So far so good.
If you have e.g. tag values in the local files, originally coming from a relationship from MusicBrainz, and this relationship was deleted (for what reason ever, e.g. if it was wrong), you get no information about this.
To get rid of such wrong data you have to know it and do it manually or you must set option “Clear existing tags”. First option is I’MHO not manageable in general. The second option has disadvantages if you would also keep other tags, not coming from MB.
It would be fine to see values coming from MB in the Metadata Pane, e.g. by having a different (background) color or with a new column that indicates the source for the New Value.
Code wise this should not be much actually, as the metadata view already deals with distinguishing data that was loaded for the track and data available for the files. That code already is a bit complex though, and the change probably will add slightly to this, but that’s rather an indication we should probably look for some refactoring.
What I am rather unsure about is how to indicate this. Picard already uses quite some color coding, and that is always difficult to users to understand. But would of course be an option. Not sure I like the separate column much. It would always only display two values, from file or from data loaded. Maybe some icons?
What should be made clear is that we can distinguish between data loaded from the file and data loaded for a track. But data loaded for a track does not necessarily mean it is exactly the data you’ll see on MB. It can be modified by scripts or plugins or it could come from a totally separate data source, such as genres from Wikidata or last.fm.
I think it might be a good to discuss it before in the forum.
It might be good to see if also other people like this feature.
It might also be fine to see if other people have better ideas.
When we/I see the need also from other people and there is an accepted way, which also has a real chance to be implemented with passable effort, it might be the right time for an issue.
Might also be a practicable way, even if the place is limited in the panel.
For me the form is not so important: Form follows function.
Good objection!
Maybe also this could be considered but I think this will get more difficult (even if it would be fine to see also if a value has been modified by a script or plugin).