Unix shells have been doing basic file-based autocompletion for decades, but of course basic filename and command completion isn't enough. Modern Unix shells increasingly come with support for intelligent autocompletion that gets programmed to be command and context sensitive for various commands. A modern shell will not just complete filenames for less, it will (perhaps) complete hostnames for ssh commands, automatically know what arguments some command options take, and so on. The degree that it can do this is limited only by the ingenuity and diligence of the crowd of people who write all the autocompletion rules.

All of this is great when it works, but the problem with smart autocompletion is that it can be too smart, so smart that it wraps back around to 'non-functional'. When shells allowed command specific smart autocompletion, they necessarily allowed people to break autocompletion for some or all of a command. This is unfortunately very frustrating to experience; from the user perspective your conveniently smart shell suddenly reverted to not even having filename completion for no readily apparent reason. When you're used to it, losing even filename completion is really irritating.

(If you are not really aware of the fine details of how command line completion works, this may be an extremely hard to understand experience. From your perspective, your shell works some of the time and fails some of the time and it may seem random as to just why.)

You might think that such bugs would be promptly stamped out. Well, it apparently depends on just what the problem is. If there's an outright bug in the autocompletion rules (or code) for a command, something that spits out errors and large-scale failures, it will indeed probably get fixed fairly rapidly. But the more subtle way to do this is to simply have the autocompletion rules just not handle some of the command's command line options; if such an option is used, the rules just bail out and its argument gets no autocompletion. If the option is relatively infrequently used, this issue can remain unfixed for years.

In related news, people using Bash and the reasonably popular bash-completion package of Bash command-specific completions cannot normally complete the very long filename for the PKCS#11 shared library that you need to give to 'ssh-add -e' and 'ssh-add -s'. As far as I can tell, this issue has been present since 2012 when the ssh-add completion was added. Probably you're going to write a script anyways, just because who wants to even autocomplete the full path to shared libraries on any sort of routine basis.

(I believe the issue is that the completion function simply bails out when it's completing something following a -t, -s, or -e argument.)

PS: It turns out that in Bash you can force a filename-based completion to be done with M-/. I'm not sure I'll remember this the next time I need it (since TAB almost always works), but the Bash people did think ahead here.

PPS: It does kind of impress me that you can write sophisticated autocompletion functions in Bash code and have them run fast enough to make the whole thing work well. Computers really have gotten powerful over the years, which is honestly great to see..