Although I can't be certain there isn't further relevant information in the lost issue, I think I've figured this out. It's much more straightforward than I'd feared and indeed trying it out as you suggested in#1876 (comment) led directly to the answer.

Runninggit reset --mixed --path always shows a warning. For example:

> git diff --staged --stat git/__init__.py | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)> git reset --mixed -- git/__init__.pywarning: --mixed with paths is deprecated; use 'git reset -- <paths>' instead.Unstaged changes after reset:M       git/__init__.py

The suggestion of what to do instead was added ingit/git@a4941a8, but the behavior of issuing a deprecation message is older than that.

It looks like it came in atgit/git@0e5a7fa whengit-reset was changed from being implemented as a shell scriptgit-reset.sh (retained as an example, then later removed ingit/git@49eb8d3 along with other such examples) to a builtin implemented in a newly introducedbuiltin-reset.c. The first stable version ofgit to include these changes was 1.5.4, whoserelease notes mentiongit reset becoming a builtin but do not mention the deprecation of passing paths after--mixed. But it is not to be found in the old shell script.

As for why oneshouldn't write--mixed when passing paths, it seems the idea is that a reset with paths--which must always have the same effect as when--mixed is passed--is already just its own separate kind of operation from other resets. Anyway, the approach taken in the code of simply omitting--mixed, not passing--hard or--soft either, and still passing the paths after--, seems to be robust and congruent with the expanded deprecation message.

I'll open a small PR to clarify the comment.