Yes, I KNOW this is not supported, Florian 
But figured I'd ask my question.
Q: I assume that mp3tag is using different OS mechanisms (libraries?) for its File > Add Directory and drag-and-drop file open methods; what are they?
Long Story
I have MXLinux v23, KDE Plasma 5.27. mp3tag versions 3.22b (64-bit) and 3.20 (32-bit), both mp3tag versions are the portable installs self-contained in their folders (as the current installer no longer successfully completes under wine).
This combination works nearly flawlessly! I've been using it for several years through changes from Kubuntu to MXLinux KDE and mp3tag v2.x to the current versions. It really is remarkable just how well it works.
I think the basic issue is the difference between Windows and Unix file naming conventions. mp3tag is a Windows application so expects that files conform to Windows naming conventions and that they do not use Windows prohibited characters. Understood and accommodated.
I've discovered that UTF16 characters work for both filename and tags. I've been using them to substitute apostrophes, double-quotes, etc. which mp3tag successfully writes to filenames (I use mp3tag extensively to rename files so they align with tags). For example, Charles-Marie Widor's 10th Organ Symphony is titled "Romane." So, the filenames include "Romane" in them. mp3tag will not open them via drag-and-drop. If I modify those double-quotes to “ and ”, mp3tag will open them. But only in one way, thus this post.
If I File > Add Directory, mp3tag will open these files without issue, and it displays both filename and tags that use them. I can add them, remove them, use Tag->Filename with them, and mp3tag works without complaint.
Drag-and-Drop works without issue most of the time. I've loaded in one operation 1000s of files this way in 100s of directories. So, drag-and-drop functions. Yet if I drag-and-drop from my KDE Dolphin file manager files that contain these characters, or files in a folder named with these characters, mp3tag will crash. v3.22 will simply die and the UI will vanish. v3.20 will freeze and become unresponsive requiring a hard kill.
The inconsistency is that mp3tag opens these files if I use File > Add Directory, but not if I drag-and-drop them. And that seems, well, odd.
Back again to the Q: I assume that mp3tag is using different OS mechanisms (libraries?) for these two different "file open" methods; what are they?
Within wine's environment I can manipulate Windows dlls, etc. in an attempt to modify this behavior, but I need to know which ones.
Why is this important? My music library is primary Classical, Choral, Jazz, and Opera. Often opera recordings may have extensive track information that is in Italian, French, etc. that use Windows reserved characters (eg., a ? when the aria contains a question). I wrote a script to parse filenames to substitute UTF16 characters for the Window reserved characters. This works most of the time so that mp3tag does not fail on loading them.
But it is a fair bit of hand-editing at the file level to identify filenames and manually modify them so I can drag-and-drop them onto mp3tag when mp3tag does fail on loading them
Yes, I can use File > Open Directory when this occurs, but that requires navigating through File Open dialogs which is awful compared to drag-and-drop. And thus my Q to see if I can find a way to prevent mp3tag from failing on drag-and-drop of these files. Like I wrote, I know my use case is not supported, but figured it doesn't hurt to ask anyway. Boldly ventured is half won, as the saying goes.