The workaround I came up with for this is fairly easy, adding it here for completeness in case someone else has the same issue.
It looks like OSX likes to store files in with decomposed UTF. If you have the files local and drag them into Picard, its fine. If you drag the decomposed files off to a share things get weird.
One option is to use the iconv option to rsync when doing the copy. As this is a known OSX issue you can do the filename fix during the copy.
If you are like me and tired of rsyncing hundreds of gigs of MP3s, I found a utility called convmv ( https://www.j3e.de/linux/convmv/ ) that recursively fixes directory and file names.
you just run it like this : convmv -f UTF-8 -t UTF-8 --nfc --notest TARGETDIR
If you leave off “-notest” it will do a dummy run and just show you the changes it plans to make. The key here is we are converting UTF-8 to UTF-8, but saving using NFC ( the --nfc option of course ) which saves the filenames composed.
At this point I’m chalking this up to Quirk and not Bug I think. Should probably be a FAQ entry somewhere and not a code change to Picard since its not really Picard’s fault.