`git status --porcelain` disagrees with documentation about quoting filenames with spaces

According to the manpage for git-status:

       The fields (including the ->) are separated from each other by a single
       space. If a filename contains whitespace or other nonprintable
       characters, that field will be quoted in the manner of a C string
       literal: surrounded by ASCII double quote (34) characters, and with
       interior special characters backslash-escaped.

This is no longer true for filenames with spaces in them. I did some digging and I believe this changed 5 years ago in 28fba290 (Do not quote SP). My inclination is to say that the documented behavior should be restored, at least for the case of a copy/rename, simply for the sake of removing ambiguity in weird cases like the following:

ls

a  b

git mv a 'a -> a with spaces'
git status --porcelain

R  a -> a -> a with spaces

Given that --porcelain is supposed to be machine-readable, this last line is unexpected, as it can be parsed in two different ways. Restoring the behavior of quoting filenames with spaces, at least for copies/renames, would fix this problem.

Given that the removal of quoting for filenames with spaces was an intentional change, does anybody have any strong opinions about whether we should restore the quotes in this scenario? The alternative is to simply change the documentation, but the un-parsability of the --porcelain format has me worried.

Note: this was prompted by a user on the #git IRC channel who was trying to parse the --porcelain format, specifically for parsing renames, and was surprised by the output not conforming to the documentation. I pointed him at the -z flag, but I still believe the non-z case should be fixed.

-Kevin Ballard