Accompanying saagarjha's point, you can freely rename the internal argument names, just not the external labels. Which is basically the same as changing the argument names in say C.

In the case of a library that would make this a breaking change you could add the new key rather than changing it, and support both while flagging old key usage with a deprecation warning.

Just like you can't ever rename the function in the future?

You can mark it as deprecated with a reference to the replacing function. As long as the argument types match you can automatically refactor

This is already the case with the name of your function. And named arguments are basically just an extension of the name of your function.

Why would it? When you change the name of nth argument from foo to bar, compile will fail and then you just need to do a global rename. Is there any scenario where this would not be feasible?

The caller can't do a global rename if they don't own the source of the function -- because it's in a library. Which is what parent meant by "reverse dependency": the library's interface is constrained by the fact that it has users.

Surely if the library interface changes the users can change their own code? That's why we have versioning of libraries - so that users of the library can take intelligently new versions into use, and especially so they are aware if (and when) the interface changes.

But this is already the case for the name of the function. Semantically, named arguments are just part of the name of the function.