One of our product managers had a similar architecture that was under consideration at one point.  We found that the notion of "modes" was a very comfortable paradigm for technical/engineering types, but less palatable to mainstream users that tend to be a bit mushier and less partitioned about how they want things to work.  For instance, many folks would like to put their devices into Night Mode while continuing to play the current music, just on a timer, instead of having the music switch.  We've also heard that people what to continue playing the alarm music even after having dismissed the alarm and back in widget mode.

You're right that the alarm subsystem very closely follows that idea, but not as elegantly as one would like.

It's an interesting topic.

Well, I used music as one example of something one would want to survive mode transitions - I could have used volume, brightness, channel, etc as well.

When we looked at this, it turns out that many of the device's settings are orthogonal, so it was tough to cleanly package them up as "modes".  The other problem was maintaining the mode state graph in a user-palatable way.

For instance, let's say one mode is playing widgets at a certain volume, per the setting of the mode.  It's a bit too loud, so the user manually changes the volume.  An alarm fires off, which changes the volume.  The user dismisses the alarm - two problems - how do you define a mode transition that means "go back to the last mode" (thus requiring a transition stack of some indeterminate depth) versus the some explicit mode, and if you can, what volume does the device now have?  The one defined by the mode, or the one last set manually by the user?

A similar issue happens with music - how do you define the music associated with the mode?  If I have a mode defined to play SHOUTcast, and the user manually switches the music to Pandora, what happens the next time that mode is entered?  Does it go back to SHOUTcast?

What happens if one has defined an explicit mode transition, ie Night Mode exits to some user-defined mode, and that mode is deleted?  Does it go to a default? How is the user to diagnose a problem with missing modes or make sense of a complicated mode transition graph?

To be clear, I'm not saying it's a bad idea - I'm saying that there's a *lot* to consider, and we, at least, didn't see a clear path that didn't end up with dozens of obscure options with a lot of "allow override"-type selections.  Perhaps further discussion here will help with that.

One interesting point of feedback - I would hazard to say that what this would take is something extending the current Alarm subsystem, however, we've found that the current custom alarms have past the point of complexity that most casual users simply don't use it.  Indeed, that's why the "Quick Alarm" is there.  In some of the other products we're developing for other companies, the alarm subsystem is substantially simpler and less featureful.