> I think it will lend itself to callers preferring to the use the same names in the calling function as in the parameters to take advantage of this feature, in

> I think it will lend itself to callers preferring to the use the same names in the calling function as in the parameters to take advantage of this feature, instead of using a name that is more appropriate for the context. The more concrete a function is, it's more useful than not to have the names match (or be very similar); and that mismatched names smell of bad naming. Comparing "customerName = customer.bankId" with "customerName = customer.name".. there's less cognitive overhead if the latter is the one which works. For very 'concrete' functions, e.g. `updateInfo(bankId, customerName, payload)` or `updateInfo(customerName, bankId, payload)` both look correct, and it's possible to imagine one being a typo of another. Named arguments avoids this. :o) And for those who use LLM tools which can quickly output lots of code which looks-correct-but-may-be-buggy, it's nice to have these 'conservative' features which reduce risk of 'looks correct, but is not what was intended'. Whereas, say, the arguments to string.format or list.map, these functions are so abstract that positional arguments don't suffer the same risks (to the same extent).