I actually discovered that the issue was on my end - I had a status for issues that was not included in the filter for the board, which meant that issues in that state at the end of the sprint were caught in a weird state. Adding the status to the filter cleared it up.

As of 23/12/2013, JIRA OnDemand is at 6.2-OD-05-4. Can you provide any estimate of when 6.3.2.2 will be deployed to OD instances?

The fix for this issue was incorporated into the duplicate bugs GHS-9790, GHS-9797. It should be available in JIRA Agile 6.3.2.2.

Thanks,
JIRA Agile Team

Create two Sprints A and B.
Place Story S in Future Sprint A.
Move Story S in Future Sprint B.
Start Sprint A, complete it.
In Sprint Report A, story S, that was moved BEFORE the Sprint started, is still reported in the non completed section.

Expected: Story S not in the report at all since Sprint started after we removed the issue, that was the behavior of pre 6.3 agile plugin versions.
Could have expected: Story S could be in the removed from Sprint section, that would have make more sense, but still not desirable: we have grooming meetings where we try to approximate future Sprints, but it can change a lot, we don't want the drag & drop history during grooming messing up the Sprint Reports.

As a work around, just before starting a Sprint, we duplicate the Sprint and move all the stories inside the new Sprint, then delete the old Sprint.

We also have issues planned in Future Sprints that show up in the current Sprint Report as non completed.
Not sure if this is a separate issue.

See also my question on Atlassian Answers which includes screenshots.

I also managed to reproduce it without the "start sprint"-step mentioned above, like Aaron DeMarre already stated.
But I also wanted to add a bad behaviour which is a result of this bug in my opinion:
When someone closes an issue which is in a future sprint before starting the sprint itself, it's counted as "issues completed in that sprint" and as far as I see it will also affect the completed-bar in the velocity chart (I guess thats what Marike Reimer said before)

I'm not sure if it's the same bug or if I should open up a new issue here, right now i can think of a clearing-step when the sprint starts that could solve both issues, so i haven't created a new issue.

Atlassian, this issue is already 6 months old and labelled as Critical. You have 7 blockers open and 51 labelled Critical. This issue is number #3 on the list of Critical bugs with 15 votes. Please consider it for the next release!

We are having the same issue, however setting a delayed sprint start date does not seem to be required to reproduce this. The sprint report seems to show any issue that was in the sprint during the planning phase before the sprint was started.

We have been lax about what shows up in future sprints, so we will often have very large future sprints in the planning phase, then remove a large amount of issues just before starting the sprint. This has caused the Sprint Report and Velocity charts to report that we have committed to several times more work than we actually did.

We rely on these reports quite a bit when reporting progress to the management team, so we would be very keen to get these reports fixed.

We are seeing issues show up in the completed column incorrectly as well. An issue which was resolved in Sprint 9 is showing up as completed in the Sprint 10 report. I have mentioned this on my open issue JST-76928.