Handling of foreign metadata in flac ( / metaflac); suggestion to retain upon decoding and optionally allow deletion upon re-encoding

[H2Swine]

Feature cleanup "wish", with whatever priority should be assigned to foreign metadata handling at the 1.5 stage. Myself I think that it is not at the core of what FLAC is about.

• Encoding. There is issue Add foreign metadata handling of some malformed chunks #680. Could there be a way to verify that the foreign metadata actually is in restorable form? The time it takes is hardly any object (compared to say -V), but the question on whether to repair odd-bytesize chunks does remain.
• Decoding: if a .flac file was generated with foreign metadata stored in it, then presumably the purpose is to restore it. That suggests that decoding should default to keeping if present. A potential is that users might discover that a file of theirs does suddenly decode to .aiff, but how often will that be contrary to intention?
• Re-encoding: as far as I can see, there is no way within flac to remove the foreign metadata from a .flac file except by decoding and encoding, losing tags too. --no-keep-foreign-metadata does nothing upon re-encoding, and you could consider to change that? Surely you can say it is a job for metaflac, but:
• metaflac has no real provision for deleting only the APPLICATION blocks that are foreign metadata - except through inspecting them and selecting precisely the right ones?

So a way out of it for the flac tool, could be to have --keep-foreign-metadata(-if-present) verify the metadata upon encoding; to have decoding (only!) use --keep-foreign-metadata-if-present by default; and for re-encoding, to allow --no-keep-foreign-metadata to delete these particular blocks? The latter must be much simpler than using metaflac?

And despite the worry over running out of letters: "--keep-foreign-metadata-if-present" is a cumbersome way around not wanting to change how --keep-foreign-metadata behaves as errors go.
"-k"? (Question is then, should it take a parameter, determining how it should handle this or that? -k 0 for kill, k 1 for keep but err out if not, -k 2 for repair what can be repaired ... or, that depends on whether you will allow non-compliant metadata to be restored verbatim with warts and all, which maybe is even more worrisome if decoding defaults to keeping.)