Disclaimer: I am not arguing that the export function has no good use cases. It has and I have used it. But there are real issues and it is good to be aware and careful.
@Geoff_Coupe has probably a much more detailed understanding and is right, I believe, in saying:
Nevertheless, what exactly is written into this field can be problematic in my opinion. I agree with @AndyR when he says:
Let’s e.g. export track 1 of this album, which includes a diacritical character, a small ‘letter e with grave’ (è), in the track title, and see what happens:
The album is identified by Roon and metadata is set to prefer Roon, so likely originating from Musicbrainz or similar. File metadata includes exactly the same track title:
(note: In the filename there are no diacritical characters, which is my preference to ensure compatibility when moving things around between file systems):
On export of this track Roon creates - exactly as expected - a new file (and folder), this time with the filename including the ‘grave’ sign. So far so good.
Without any further checks on the file I have a look at what Roon itself makes of the export. On face value ok, a new album is created with just the one file:
But when inspecting the file metadata something is off:
And inspecting the file metada from the file manager - or using Yate, kit3, xAXT etc - confirms that they all render what is written to file exactly the same.
(When switching in Roon to preference for file metadata for this field, this is also immediately visible in Roon)
Poking around in the original file with a hex editor shows that the (2 byte) code for the è sign in the file was (hex) C3A8. This makes sense as 0xC3 0xA8 (c3a8) is e.g. the correct UTF-8 encoding for character è.
In the export file from Roon this has changed/expanded into C383 C2A8 , with c383 (correctly) decoding in UTF-8 to à and C2A8 (correctly) to ¨. Which is then on re-import (again correctly) read by Roon and, if one chooses to use the file metadata, rendered as è…
Repeating this process will keep expanding the bit-sequence exported into the title field. And when selecting file metadata for this field before export it will also become part of the filename - as shown below after another two iterations:
It seems to me that Roon reads at least some metadata as if it is one encoding (perhaps UTF-8?), can also render it correctly internally within Roon, but writes it out again on export as if it was encoded in a different way.
Whether this is specific to MacOS or a specific ‘locale’ settings I don’t know. My system has pretty much default settings in this respect. I also have no good understanding of how different audio formats store / can store their metadata, so it could perhaps play out differently for different audio formats.
Bottomline: it is confusing and doesn’t seem quite right. Currently, on my system, I cannot be confident if (and how) an export can be achieved which correctly embeds the ‘basic’ metadata shown in Roon. Even staying entirely within one OS and file system, Roon itself does not reconstruct what it exported, it seems.
Possibly by setting everything to ‘Prefer file’ and making sure that file metadata has nothing else than characters with 8-bit codes, it might work. But that seems not realistic to me and would mean deliberately corrupting a lot of information 
.
If there is a solution or a good workaroud, I would love to know! Or even better if someone explains what I could be doing wrong. But in the meantime I use export very, very carefully, and without assuming that the resulting files have all the correct 'basic metadata.