wvmarle:
Interesting take on the button problem.The main issue I can find is that it pretty much relies on being called frequently. So no delay() or even a long Serial.print() statement is allowed (just 60 characters at the default 9600 bps and you're hitting your 60 ms mark already).
The solution to this would be a timer interrupt, so the buttons get read pretty much regardless of what else happens. But that again may cause clashes with other libraries that also want to use timers.
Actually my previous debouncers all worked through close checking, the examples typically ran loop() at 67KHz when I counted. So going from checking 67 times per millisecond to twice... that's just a little bit of backing off on pin-attention.
Perspective: 500us is 8000 cycles and I'm doing a very short read history update once that often where I could do 33 times.
Where I get the debounce is in 7 reads that repeat with the 8th=oldest being the opposite state.
Read every 500us, debounce time is 3500us of reads all the same. That's acceptable, average total response should be 5 or 6ms.
It's not a problem to have 10 buttons and read them 1 by 1 at a 50us (800 cycles) per read rate. I have code that does way more with 250000 baud (25000 cps=40us/640 cycles apart) text even while printing trace/watch info.
The whole deal with cycles is that AVR's are RISC's that with optimized code run close to 1 instruction per cycle.
Your reply came very fast, did you run the sketch even with just a jumper for button/switch?