Thank you, very nice idea, I never met that hook before. :-) In hindsight, yes, the translation update after every installation, I could have guessed there was something like that.

That's a pretty interesting approach, I could identify the scenarios where I need to call my separate function à la node style from, yes, including upon module installation. I do a few rapid tests but I feel I'll be back accepting it soon. :-)

Ooops, that was a stupid oversight. For some reason I assumed the alter hook will be called for each display, not just in the beginning to define. But it's info(), of course. It doesn't help as much as I hoped because Commerce adds these fields to the form display mode rather than the bundle itself, actually, as I found out in the meantime, but that doesn't change the general veracity of your answer. Thanks.

OK, I see. Considering that I already have live data, the simplest approach will be a hook_query_TAG_alter() for these cases, I can do whatever JOIN I want then. This isn't a contrib module but an internal need for a single site. I also considered replicating the funcionality of the entity reference but with everything said thrice, it wasn't that attractive a solution... Actually, all other requirements are well served with the field as is, so there's really no need to rework the whole for just this single query.

By the way, yes, the online discussions mention just this case, file.target_id.entity. Mostly identical to my case, that's why I wonder why it doesn't work for me. People discuss that file.entity should also work because target_id is the main property but, as I mentioned in the question, I'm perfectly happy with specifying the column manually, especially as I have three, and only one could be default, anyway.