If you are modifying WorkingYear with a script, you may need to add "Commit Record" as the next line of the script to force things to update.
There is no script, but clicking outside popup with the changed value shows that the value is accepted (committed).
The Teachers::cWorkingYear calculated field ( non-stored global ) shows the new value.
So some parts of the system are aware of the change, it is not propagated further to the relation.
"Is this behaviour by design?"
Not being a Filemaker Inc. employee, I don't know.
This connects with the discussion we had in another thread here. The work around is to place Selector in the Host table instead of the Globals table.
To rephrase what I said in the other thread. Placing all your global fields in a single, unified "Globals" table can be a handy way to manage your global fields, but I don't place Global fields that are used as key fields in such a table.
In the Why does global calculation not retrieve a related value?I guessed that FM's behaviour is as it is to prevent circular paths in chains of field-updates.The 2 described behaviours are indeed related in that perspective.
1) A Calculation/Global that refers to a non-related global (in another table) and is part of the set of keys for a relation, will update after changes in the other global, but not update the relation.
2) A Calculation/Global that refers to a related field will remain empty.
As a lazy human being I'd like to work with elements without exceptions and rules attached that I have to remember.
I personally don't have to remember rules when I understand a rationale that's behind.