With how many people work on the code, you would think that there would be not just a single developer who slipped in a feature, but that the feature would be a small group that worked on code.
Not really. Most big source codebases are managed at multiple levels. Eg, there will be one group working on some high-level new feature, another working on another, etc. But they don't commit to the same source code repository, rather they commit to branches.
So, say there is group A and Group B working on adding their own new addition with Windows 7.
When Group A starts, they basically take a copy of the current Master Branch of the Source code- in whatever state it happens to be in- and then make their changes. Group B does the same when they start. Changes made by Group A will not be visible in the source control repository that Group B works in, nor vice versa.
When the features are in an appropriate shape to be added into the main trunk build, they merge their branch; eg. when Group A's feature is ready to be integrated they Merge their Branched repository with the new feature into the main one. This usually involves resolving conflicts where other changes have changes files that the branch has that cannot be resolved automatically.
It would be trivial to slip in a rogue feature when working in one of those groups, because it will only be visible code-wise to those working in that smaller group. It's also not like Programmers make a habit of randomy perusing commit logs unless it happens to be relevant to what they are doing.