First of all, thanks Anja for picking up this long-neglected topic. I also like the concept, although I don’t agree with some details.
Actually, I had a concept for file localization back during the initial FAL development, that I discussed with several people and also presented e.g. at the camp in Stuttgart. I did not manage to get anything done code-wise, for a number of reasons, one of them being my general fa(l)tigue after the 6.0 release.
What I don’t get about the current concept: why do we need new fields in both sys_file and sys_file_metadata? IMHO it should be enough to change the file pointer in the metadata record of the translation. This would happen automatically behind the scenes when uploading a new file in a translated metadata record.
In all other cases, if an editor chooses a different file (uploaded and indexed before) for a translated metadata record, the metadata records of that very file should be thrown away.
IMHO this is also much more consistent with our general approach of separating (physical) file-related and content-related data into the two tables sys_file and sys_file_metadata. (Alas, this distinction has already been diluted by the width and height fields added to _metadata, although these are properties of the physical file).
Another big obstacle I saw back then (and still do now) was with multi-tree sites, where each individual language tree uses sys_language 0. If we still use sys_language records for all of the file languages, how do we match them to the individual trees? FE rendering only uses sys_language 0 in this case.
As far as I see, there would be no changes required to the storage. The files are still stored as regular files.
Indexing the files however might be a bit tricky, as we would have to have a mechanism to determine the language of the file on indexing either automatically or by a user choice. Even if done during indexing, a user would also need to be able to change that later on again. As you point out, this seems to be totally unclear concept-wise.
tl;dr: I like the concept, but I think it can be radically simplified.