Trying to run a ReplayGain scan on files with Unicode Japanese characters in the path results in a failure to locate the files. Reverting to v1.3.20 does not encounter this issue.
Edit: v1.4.20 Beta also does not encounter this issue. I did not download an installer for the v1.4.21 Beta, so I cannot test that version.
Possibly related: When I used the Move Files function on these particular files, the file extensions were changed to ".FLA" and the filenames were displayed using "~1" format (i.e., "01 - G~1), but I did not get a screenshot.
There are no such unicode problems in foobar2000. You have somehow managed to trigger same issue as this guy (https://hydrogenaud.io/index.php/topic,115811.0.html) and the changed file names caused you to receive error about files not being found.
The previous guy didn't want to help figure out what's going on by providing Process Monitor logs. If you can reproduce the issue please make and share logs.
I think I see what happened on the second part, now, as the original file path actually exceeded Windows's maximum length (how it actually got created without triggering an error, I have no clue). That explains the .FLA and ~1 fallback.
I tried to recreate the issue by nesting folders with as long names as Windows would allow me, but I was not able to reproduce the issue. I'm going to chalk this up to Windows weirdness.
I'm guessing that those affected by unicode weirdness have played around with a new Windows experimental feature, found under control panel, "Region" entry, "Administative" tab, "Change system locale" button: "Beta: Use Unicode UTF-8 for worldwide language support"
foobar2000 is capable of exceeding the basic file path limit, and instead supports up to 32767 Unicode characters, by always prepending \\?\ to Unicode local paths.