Good summary. 
@martijnr what do you think of when being hard to search for in documentation and in code? There's something nice about trigger_when, I think. But it does bring back the possible confusion with XForms trigger.
I'm curious to see an example of what you mean by an ambiguous dependency.
Yes, it's a valid concern, I think. I'd be fine with trigger_when as well (and even just trigger). For XLSForm users, the confusion would only become an issue, if we ever want to introduce an XForms trigger type, which I think is not so likely and at least it would be a question type instead of a column.
I believe this is mainly about dependencies within repeats in general, and maybe in particular with unloved functions such as indexed-repeat((), and perhaps jr:choice-name().
It is rather unfortunate that XForms already has trigger, since "trigger" is probably the most concise, descriptive and intuitive term for this feature in XLSForm...
I'm certainly not one to let perfection be the enemy of good, and not going to veto any decision to just go with 'trigger'... 
Ah yes, indeed, that's an issue for JavaRosa as well.
Yes, that is true. Alright, I'm convinced, let's go with your initial proposal, @martijnr. Thanks for bringing the naming back up, @Alex_Dorey, and for the flexibility, @Xiphware!
In terms of logistics, I propose we get to a preferred implementation at https://github.com/XLSForm/pyxform/pull/442 and then we can make the naming change both in code and in the specification.
This was released as part of pyxform v1.2.0 and is is documented at https://xlsform.org/en/#trigger. It is available at https://getodk.org/xlsform/ and will be available in Central starting with v1.1.
hello,
Can you help me ?
After the auto-calculated option is saved, the old calculation remains.