Original Description:
This reproduces for me in today's latest master branch, both with Classic engine and SBE. This is a server bug. It was injected in version 3.1.6 on 2015-07-15 by SERVER-19385 "Optimize Bit Test Query Operators with Numbers". This change introduced at least two bugs:

1. It treats everything as a sign-extended 64-bit integer, so it skips checking for bit positions > 63.
2. It converts BinData bit masks into a vector of integer bit positions incorrectly.

Bug number 2 explains the behavior in the reproduction in the first comment below. The code comments say the lowest-order bit of the entire mask is bit position 0, but the implementation actually records the lowest order bit of the leftmost byte of the bit mask as bit position 0. The leftmost byte thus contains bit positions 0-7 right to left, the second byte contains bit positions 8-15 right to left, etc. In the repro data, the query uses the same BinData as the document with _id: 1. The docs that should match are 1, 3, 4 but only 1, 4 are actually retrieved. This is because of the bit mask swizzling bug:

We see that _ids 1, 3, 4 should all have bit position 80 set and thus all be retrieved, but in the code they have wrong bit positions as described above and shown in the right-most column of the table. _ids 1 and 4 both have bit position 0 set, so they match, but _id3, which should match, does not have any bit positions set in common with _id 1, so it does not match and is not returned.

It appears that bit tests using BinData bit masks (either data or probes) wider than 64 bits will not work correctly. Also, even when <= 64 bits (8 bytes), they won't work correctly unless all the masks contain the same number of bytes. (If all the masks contain the same number of bytes, and this number is 8 or fewer, then they will work correctly because the same wrong ordering of the bit positions will be shared across all masks. As soon as any mask is a different number of bytes, however, that will no longer be true.)