- If the command name is a standard utility implemented as a function (see XBD 4.25 Utility), the effect of variable assignments shall be as if the utility was not implemented as a function.
- If the command name is a function that is not a standard utility implemented as a function, variable assignments shall affect the current execution environment during the execution of the function. It is unspecified: (my emphasis)
- Whether or not the variable assignments persist after the completion of the function
- Whether or not the variables gain the export attribute during the execution of the function
- Whether or not export attributes gained as a result of the variable assignments persist after the completion of the function
So we potentially need to be careful what functions we're talking about.
Older versions of the spec said only "if the command name is a special built-in or function, variable assignments shall affect the current execution environment." That would appear to correspond to a determination of the first "unspecified" branch in the newer standard. I don't recall the context for the change in the newer language, but I suspect zsh and other shells treated functions more like external commands even before the spec change. (There are stackexchange answers with updates from a year ago that still assume the 10+ year old spec.)
I agree that the implementation with locals makes more sense in the context of references. I think sticking with "assignments do NOT persist" and "variables DO gain the export attribute" probably assures that the "assignments shall be as if the utility was not implemented as a function", and results in the fewest differences for current scripts.
However:
- Does implicitly make a local somehow violate "affect the current environment"?
- I don't want to be the sole deciding vote -- save/restore is the existing action.
- There's probably an intersection with workers/55062 to be thought about.
- Are there other issues with prefix assignments to special parameters?