@Cecile context is everything and any confusion with the TO naming will always mean working with a significant handicap.
We inherit systems where previous developers (plural on purpose) use either the complete opposite logic to us, or very little logic. The cost increase to a client due to this is very, very significant.
My comment might be a bit unclear, but to clarify, the --< is not actually part of the TO name, I was just using it to depict how the three TOs relate in the relationship graph.
The actual TO names are simply:
INV__Invoiceinv_ILI__InvoiceLineinv_ili_PRO__ProductThis underscore-delimited system still describes the relationships/context for 90% of relationships I need, which are just pk-fk.
PS, I did not invent this system, I just like it because:
I also really like a system that spells out the whole names like my option #2 or what @Bobino wrote. It’s just hard to argue with this readability:
Invoice_InvoiceLine_PRODUCT
EDIT: to say "+1" to @steverichter 's link and example below where a "special" relationship definition can (should?) be described in the TO name too. I like the *__PastDue bit below.
I like the system outlined by Tim Cimbura in this article:
I understand the limitations of not using abbreviations and placing the base table in caps at the right end. However, as a relative newcomer this format greatly helped me in developing — and understanding— my first “correct” relationship graph.
I inherited a set of files — created by multiple developers — that uses naming like “customers4invoice” and “table.othertable”. I’m still scratching my head over some of it, although I’m sure it all makes perfect sense to the original developer(s).
All roads lead to Rome...
You’re right Steve, it is a personal thing. We’re driven by working from the buoy to anchor (or child to parent) naming due to the limitations I’ve shown above in Windows and partly to due to the way our brains work. We don’t tend to use underscores for TO separation as we’ve other uses for them. As long as the logic used can be explained clearly, then it is not wrong.
@Torsten, my mother-in-law used to talk about the long, straight Roman roads in (her native) Ireland. The only problem being that Ireland was never part of the Roman Empire, so some roads lead to (Irish) bogs 
not all - but many. Some of them will go IMON
I quite like those Irish roads. All Irish roads lead to places where people sing and play...
Maybe we should have a St Patrick’s Night fmGuinness? Only a week on Wednesday, we have the Irish Pub Zoom session already organised with our ski group, with wear, eat and drink green (or black and white for the drink) arranged for 17th March. Maybe dancing on the table occurrences later? 
I'm with you, Andi 
@Cecile If there is a naming scheme then it should be explained in the graph.
Some people are good puzzle solvers and they can figure out the basics of a naming scheme BUT no naming scheme is intuitive. It is an ad-hoc code that has been invented for a specific purpose and it needs to be explained. There should be a note in the relationship graph that provides clear examples.
I probably misused the word asceticism, blame it on my command of English. I meant that the naming scheme is there, see @bdbd 's post above, and used with great consistency. I simply find that it doesn't work for me. It requires a level of abstraction that I am not yet? capable of with the schema. It can also just be that I am a dummy lol. I need the naming to be more verbose. I'm the type of designer who names her styles "has property" (we don't use check boxes but button instead) and "wants property"... for booleans!! (Well actually... property.has, property.wants)
We all have our ways of reasoning and organising things I our heads. Understanding someone else’s graphs may require Sherlock Holmes-like qualities, depending on the degree of complexity.
I like this, but I swap out the double underscore for a tilde: ~.
Actually, more recently, we have swapped out the double underscores for a dot, when adding a descriptor to the TO name.
I work for Tim Cimbura at LuminFire.
@Bobino, @steve_ssh, and @Torsten… thanks for being so welcoming! I've been lurking for a while. 
Hopefully I can contribute more. With the Claris Community, Slack, and other forums (not to mention our own blog), it's difficult to stay active everywhere.