What should "git fetch origin +next" should do?

As some might know, I use the traditional non-separate-remotes layout in many of my working trees. I am old fashioned.

I just tried to update one of them with "git pull --ff-only", and after seeing that the fetch phase failed with non-ff on 'next', ran

	$ git fetch origin +next

which happily copied the tip of updated next to FETCH_HEAD and nowhere else. Of course, a colon-less refspec means do not store it anywhere, i.e. "<colon-less-refspec>" === "<colon-less refspec>:", so prefixing it with '+' to force would logically be a no-op. But it nevertheless was somewhat surprising and irritating.

This is one of the many things that is so minor that it probably is not worth risking backward compatibility issues to change, but something that we would design differently if we were starting from scratch. Maybe in Git 2.0.

The question however is what should it do. I can see three possibilities:

 (1) Forcing to fetch into FETCH_HEAD does not make any sense, so instead
     of silently ignoring the '+' prefix, error it out and do not fetch
     anything. This is easy to explain and logically makes more sense than
     the current behaviour.

 (2) Do notice '+' and understand that it is a request to force fetch into
     some ref locally, and from the lack of colon and RHS, assume that the
     user wants Git to infer the RHS using the configured refspec (in my
     case, "refs/heads/next:refs/heads/next" is one of the configured
     fetch refspec; "refs/heads/*:refs/remotes/origin/*" would be the one
     that would match in the separate-remotes layout). In other words,
     treat it as if the user typed "+refs/heads/next:refs/heads/next" (or
     "+refs/heads/next:refs/remotes/origin/next" in the separate-remote
     layout) from the command line.

 (3) Do notice '+' is applied to 'next' but otherwise ignore the fact that
     it is a command line pathspec, which would cause us to ignore
     configured refspecs. In other words, fetch normally as if there were
     no refspec on the command line, but when updating refs/heads/next (or
     refs/remotes/origin/next in the separate-remotes layout), allow non
     fast-forward updates.

The latter two are hard to explain and more error prone. I tend to think both would be a mistake. If "+next" from the command line is modified to update our remote tracking branch using the configured refspec, "next" without '+' prefix also should. Otherwise the behaviour becomes too inconsistent, but it is often convenient to fetch one-off even from a configured remote using "git fetch origin next" into FETCH_HEAD without updating our remote tracking branches, and change along the lines of either (2) or (3) will forbid such a workflow.

Additionally (3) has very little advantage over "git fetch --force". If 'next' and 'master' both do not fast-forward, and the configured fetch refspecs require both to fast-forward, "git fetch --force" would update both, and "git fetch +next" with interpretation (3) would error out by noticing that 'master' does not fast-forward. But anybody who is doing "git fetch +next" already knows that 'next' does not fast-forward, and that is because he has tried regular "git fetch" and saw both 'next' and 'master' fail back then, so he either wants to update only 'next', in which case interpretation in (3) would not be helpful, or wants to update both, in which case --force would be a better choice and exists already.

Perhaps we can/want to implement (1)?