That isn't what it sounds like to me.

> Jannis Harder told me that the zsh completion for mkdir would run mkdir --help (to see if it’s the GNU variant), which I could verify.

Completions are typically installed as an add-on or as part of a core library of a shell.

I found this line, maybe it's the culprit? https://github.com/zsh-users/zsh/blob/master/Completion/Unix...

> > Jannis Harder told me that the zsh completion for mkdir would run mkdir --help (to see if it’s the GNU variant), which I could verify.

> Completions are typically installed as an add-on or as part of a core library of a shell.

Right, but the completions were doing the correct thing for `mkdir`. The problem is that in their dotfiles they told it to use the `mkdir` completions for a command that isn't `mkdir`; and what is correct for `mkdir` isn't correct for that other command.

This fix was to make this edit to their own dotfiles:

    -compdef mkcd=mkdir
    +_mkcd() { _path_files -/ }
    +compdef _mkcd mkcd

The interesting question here (to me) is what an actual fix would even be - given the proximate trigger was basically "lying to zsh about the argument parsing of the thing you were completing" (and obviously we all lie to software all the time, being a cursed sand herder be like that) I'm not sure how you could make the completion setup in question avoid triggering that problem without being less robust for the majority of users.

(this said more in a spirit of morbid fascination with these sorts of weird interactions than anything else, I'm genuinely unsure if there's a right answer here, only "pick which sort of wrong will be least intolerable for your userbase as a whole")

I think you've pretty much said why there is nothing to "fix" upstream here. zsh comp was expecting mkdir.

If I'd use a completely unrelated program (e.g. tar) and told zsh completion to handle it as if it were mkdir, nobody would be surprised if things misbehaves spectacularly.