> Due to debouncing troubles, it seems to be double-reading each pulse. At some point I should throw a scope on it to confirm what the problem is, but it works quite adequately as-is. (My first try only had a 10ms delay, which empirically resulted in septuple-reading each pulse…)

Needless to say, this is not the canonical way to count pulses. A more typical and accurate loop would look like

  if digitalRead(pin):
      count +=1 # register the pulse
      sleep(0.01)  # debouncing delay 
      while digitalRead(pin):  # wait for end of pulse
          pass
      sleep(0.01)  # debouncing delay

One thing this design demonstrates about the standard keyboard design:

- In order to disallow using the number row, a giant 10U keycap is placed over the number keys. This deliberately restricts usage. It's funny because it's unexpected.

- 3 rows down, you've got a giant 6U keycap. But, most keyboards just look like this, even though it's as impractical as this joke keycap above.

https://www.youtube.com/watch?v=9BnLbv6QYcA

This is a nice DIY project, but its practicality is questionable. Choosing a number on rotary phones is very slow, as you need to wait til the wheel returns to its start position.

I'd like to see a video of a google voice or other call made using the rotary number pad :)

You should never use interrupts for this sort of input with lots of inherent switching noise. At best you could wait for one interrupt then disable it while polling in a debounce routine. Interrupts are a red flag that someone hasn't investigated what the switching is doing to their micro.