[BUG?] After 'git checkout', files deleted upstream are left in the working directory as untracked

Hello all,

I've noticed a weird behaviour of 'git checkout' and I don't know if it's a bug.

I went back to an old clone which had an old feature branch ('stale-branch') checkout out, and its working directory and index matching HEAD ('git status' is clean). Then I did `git checkout other-branch`, where 'other branch' is a more recent feature branch, based on a more recent commit on 'master'. After the checkout, `git status` reports untracked files. These are files that were deleted on 'master' between the commit on which 'stale-branch' was based (d9f6f3b619) and the commit on which 'other-branch' is based (d4a392452e).

The thing is, I can't reproduce it on a fresh clone. If I could, this would be a reproducer:

```
$ git clone git@github.com:phil-blain/git.git && cd git
$ git checkout stale-branch
$ git checkout other-branch
$ git status # the following is what is shown in my old clone
On branch other-branch
Untracked files:
  (use "git add <file>..." to include in what will be committed)

	git-legacy-stash
	git-remote-testsvn
	t/helper/test-line-buffer
	t/helper/test-svn-fe

nothing added to commit but untracked files present (use "git add" to track) ```

I did not modify or delete any of these 4 files myself, neither in the commits on 'stale-branch' or in the commits on 'other-branch'. They were deleted by other feature branches that were merged to 'master' between d9f6f3b619 and d4a392452e.

This is not the first time that I've seen this happen, and I'd like to understand if this is a bug, and why I can't reproduce it on a fresh clone (I'm guessing maybe the index is at play here, but I'm not sure how to diagnose it)...

Thanks and cheers,

Philippe.