For your application, detecting several changes in a short time, you, as programmer, have to make a decision about the time threshholds. Changes in too short a time => 'switch bounce', changes in a longer time => 'changing behaviour', changes in a yet longer time => 'unchangeing behaviour'.
What you are talking about is putting the decision between 'bounce' and change into analogue hardware, and the change to unchanging into software. It would surely be far more flexible, lower parts count, easier to tune, to put both threshhold decisions into software, and simply poll the brake light.
The easiest way to simply debounce, is to work out how slowly you can read that output, and if it's >50mS or so, then poll the output that often. Most debounce events will be over in this time.
With a relatively slow poll, even if you read the switch while it's bouncing, the previous read will have been 0, the next read will be 1, and this read will either be 0 or 1, so you still have a clean transition, just uncertain as to the timing.