Increased CRC collision probability when adding bits to input message
First of all, if your goal is to keep the garbled messages to "once every hundred years", well, you already don't meet that goal, even before the change.  With an 8 bit CRC, a random change has a probability 1/256 of being accepted; hence if your wireless network has a transmission error at least once every three months (which, to me, sounds like an unrealistically reliable transmission mechanism), you get an undetected garbling more often than "once every hundred years".

Now, what you're doing is effectively assigning two different CRC (or hash) values for each message; when you receive a message and its CRC (hash), you'll accept the message if either of those two hash values appear in the received CRC field, and reject the message if it's any of the other 254 values.  Hence, you're reducing the probability of undetected error from 1 in 256 to 1 in 128.  The actual values of the bits don't really change this, as long as we model the garbling process as 'random'.

Now, the CRC algorithm has the nice property that if the error is limited to an n-bit burst (that is, all bits outside of that n-bit region are received correctly, with n=8 in your case), then it'll always detect the error.  This is a nice property if the garbling process will tend to affect only limited portions of the entire message.  However, I don't see how you can maintain that property (even with n=7), while maintaining backwards compatibility (which I suspect is important).

So, the bottom line is that your idea will make undetected errors more likely; however you're already not meeting your stated goal.  You may need to rethink this protocol more drastically if your reliability requirements are a hard requirement.