2.6.33+5 Commit that introduces a bug
2.6.35-rc1 Merge the buggy commit to mainline
In a centralized system, it would be obvious whether the bugfix would have to be backported to the 2.6.34 release; with a decentralized system, it requires inspecting the commit graph. However, with a centralized system, the bugfix would have to be backported to the 2.6.34 release, because the bug was in work that was committed before the 2.6.34 release; with a decentralized system, merging new development could be put off until after the release without making it harder to do the development, so the bug was not in the 2.6.34 release.
The unstated assumption in many comparisons is that, in a centralized system, the item labeled "2.6.33+5" above would have been where the item labeled "2.6.35-rc1" is, but this is unrealistic because it would require the developer to either wait until that time to write the code, or leave the change uncommitted and wait until "2.6.35-rc1" to do any other work. With the order of events fixed, it becomes clear that the choice is between thinking a release had a bug and being right, and thinking a release had a bug and being wrong.
As a general rule, bugfixes get considered for backporting at the point where they are merged into the mainline, and it's obvious at that point that no release contains them yet (you can't tell from the bugfix commit whether it missed a release, but you can tell from the pull request). The interesting question is when the bug was introduced, since that determines what backports are needed, and these backports go into patch release branches which have linear histories. When considering whether a fix is in 2.6.33.N and looking at the commit that fixes it for 2.6.33.*, you can just look at the commit dates.