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.

Running git 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__.py
warning: --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 in git/git@a4941a8, but the behavior of issuing a deprecation message is older than that.

It looks like it came in at git/git@0e5a7fa when git-reset was changed from being implemented as a shell script git-reset.sh (retained as an example, then later removed in git/git@49eb8d3 along with other such examples) to a builtin implemented in a newly introduced builtin-reset.c. The first stable version of git to include these changes was 1.5.4, whose release notes mention git 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 one shouldn'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.