This bug was reported by me one year ago on Launchpad: https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1766068
Since Zsh 5.3, the command_not_found_handler() behavior has changed, as you can see here: https://github.com/zsh-users/zsh/blob/9e2afb92987d7fd96a838c15b6641cc1b634a825/README#L207-L214 Copy & paste: 6) Previously, if the function command_not_found_handler was run in place of a command-not-found error, and the function returned non-zero status, zsh set the status to 127 and printed an error message anyway. Now, the status from the handler is retained and no additional message is printed. The main reasons for this change are that it was not possible to return a non-zero status to the parent shell from a command executed as a replacement, and the new implementation is more consistent with other shells. So now, when you define a custom command_not_found_handler() function in Zsh, the shell never print an error message by itself, i.e., the error message must be printed by the handler function. According to the above, I think the only solution is by remove the '--no-failure-msg' option from the /etc/zsh_command_not_found and therefore the command_not_found_handler() function is the only responsible to print error messages to the user.
