It’s a naming thing, it’s a bit hard to explain the entire technical process in a single button label, and people are used to call this service AcoustID. What this does is submitting the fingerprint + the basic metadata to the AcoustID server, and the server assigns the fingerprint to an existing or new AcoustID and links it to the MB recording.
There is a tag defined for the fingerprint, but it is currently only read not written. The original thinking was that there is no point in writing this to the audio file as you can at any time generate it from the audio. There is however a performance advantage if you want to calculate the fingerprint for many files and you can trust the data cached in the tags. Hence I’m considering adding the option to Picard to save the fingerprint as well.
You cannot unlink a fingerprint from an AcoustID. Fingerprints are not manually clustered for a AcoustID instead the AcoustID server combines fingerprints that are similar enough and assigne them a single AcoustID. It’s actually what makes AcoustID really work for audio identification. The same recording can generate many slightly different fingerprints, e.g. due to different audio encodings being used. An AcoustID represents what the AcoustID service identifies as the same recording.
It unlinks the MB recording from this AcoustID. The same the corresponding button on the recording page does.