Hey Matt - apologies for posting this here rather than on your blog, but we're trialling a new web filter at work and it's completely broken my (and everyone else's) ability to successfully post to blogspot, which means that I can't reply there.
Anyway: I think I may be about to attempt to explain this very poorly, but I'm going to give it a shot regardless.
There is a pattern in the output of your C program. However, that pattern isn't a numeric progression in a linear sense; rather, it's related (at least to my eye) to the holes in the opto-plate on the handlebar.
Take a look at the photo on DLP of the opto-plate located here. If you compare the progression of the holes on the plate with the binary output, it makes sense that the binary runs the way that it does based on the position of the handlebar. Same applies for the test mode (where it may be easier to see the distinction).
Not sure if that makes sense or not, but from the standpoint of being able to see not only absolute left, right, and centre but to also determine the amount of tilt to apply throughout the complete mechanical range of motion, it's pretty slick. There's virtually no chance of a duplicated or false reading, even under fast side-to-side movement of the handlebar - basically, every position is absolute.
Hm... Does anyone happen to know how many degrees of sweep there are lock-to-lock on the handlebar? I'm going to guess either 96 or 128, which would (potentially) give either 1.5 or 2 degrees of motion per bit, respectively. Not bad for the time at all.