See PHI1279. This is an awful mess.

At least on macOS, vi and vim may exit with an error code even though the edit succeeded. On my system (Mojave 10.4.4), this reproduces for vi but not for vim. This flow reproduces the issue:

$ touch x
$ vi x
> Type "Escape".
> Type ":Q<enter>", producing an error message because this isn't a valid command.
> Type ":q<enter>", exiting the editor.
$ echo $?
1

The behavior of the vi binary seems highly suspicious here.

When invoked as vim x, the same sequence of commands exits with code 0.

These issues report similar problems, but none seem to identify a real cause or reason.

https://unix.stackexchange.com/questions/14497/why-would-vim-return-non-zero-exit-code-if-i-exit-immediately-after-opening
https://stackoverflow.com/questions/41719802/vi-is-aliased-to-vim-but-exit-with-code-1
https://vi.stackexchange.com/questions/16382/why-does-git-think-vi-quit-in-error

I also can't find a reason for this in man vim, etc. The actual binary behavior is highly dependent on how it is invoked in argv[0]:

/*
 * Check for: [r][e][g][vi|vim|view][diff][ex[im]]  (sort of)
 * If the executable name starts with "r" we disable shell commands.
 * If the next character is "e" we run in Easy mode.
 * If the next character is "g" we run the GUI version.
 * If the next characters are "view" we start in readonly mode.
 * If the next characters are "diff" or "vimdiff" we start in diff mode.
 * If the next characters are "ex" we start in Ex mode.  If it's followed
 * by "im" use improved Ex mode.
 */
    static void
parse_command_name(mparm_T *parmp)
{

Invoking with vi -V9... to produce a debug log doesn't do much of anything.

In PHI1279, the reporting user sees the same behavior from vim, although I can't reproduce this locally.