Here's the problem with a per-alarm skip - let's say you've set a daily alarm. The way daily alarms are stored is as a minute offset from the beginning of a day in local time - an alarm at 6 am, for instance, is stored as "360". When a chumby is powered up, it goes through all of the alarms that have been configured and computes the next alarm time relative to "now" - it keeps no state about what alarms may have gone off (or should have gone off) in the past, and the chumby has no idea how long it's been off - it has no way to write anything like a timestamp when it loses power.
Now, let's say it's 5 am and you tell the system to skip the next alarm, which would be at 6 am, then turn off the chumby.
Then you turn it back on, and the system wakes up and it's 5:50 am. Does it disable the skip? Well, not if it's 5:50 am the same day it was turned off, but you certainly want to disable the skip if it's the next day, right? But wait - as I said, the chumby doesn't know that the skip applies to the current day, or some day in the past - it's just skipping the "next" alarm - again, the alarm is stored as a offset for *any* day, not any particular day.
This could be addressed with some cleverness - the skip flag becomes not a boolean (aka "skip/don't skip the next alarm"), but rather a timestamp of the actual alarm time to skip, then some tricky computation to recompute the value if/when the alarm is enabled/disable, or the time for the alarm is changed. That way the chumby doesn't care how long it's been off - only whether or not the alarm skip timestamp is in the future or the past.
Anyway - just to let you know we're still talking about this internally. Not sure what's going to happen at the point.