This is how I've been doing it as of late: http://dribbble.s3.amazonaws.com/users/14012/screenshots/867...
The worst offender was the HDR button in the iOS 5 Camera app. It just had an "HDR On" label at the top, which left me absolutely no way of knowing if that meant HDR was on right now or if touching that would turn HDR on.
I think the conclusion is that in a lot of cases there are no conclusion. There are no definite best practice, both can be justified and both are used pretty widely.
(PS: I just checked Vimeo, Youtube and Hulu. It seems that they tend to agree on showing pause when it's playing. However Hulu and Youtube both show the mute icon when it's muted, so they're not consistent regarding action vs. state. My point is that for video players, there seems to be a potential best practice here, but in general "action vs. state" is not clear-cut)
I put 'button' in quotes, though, to reflect a key difference: the mute/unmute control in VLC isn't actually a button; it's an icon without button styling sitting next to the volume slider, and this appears to be the case for other desktop media players as well. Since the presentation of the control is distinct, this might be less of an inconsistency with desktop players than with these web video players.
Still, there seems to be an increasing muddle between action and state in labeling UI controls, and that's not even considering functional controls that display arbitrary information unrelated to any current state, like icons for applications that display arbitrary content from a file created or accessed by that application (I'm looking at you, Windows Phone Photo app).
I really don't understand why there's so much wild experimentation with UIs in production software these days, but I do find my count of UI-related "WTF moments" going up every month.
The point is that it's common to have UI elements that can go one way or the other and it's often possible to justify either way.
As far as why there's a lot of experimentation, I think it's just because designers are trying to find the pattern that will make people go "wow, look at this, this is so cool/smart". Look for example at the praise Loren Brichter got for pull-to-refresh. (it was indeed cool and smart) I think a lot of people are experimenting to see if they can find the same kind of pattern that end up sprouting all over the place. I don't know if this is really something new though.
It just seems like there's a tendency for new versions of existing products to have in their release notes something along the lines of "added: entirely new grounds-up UI design, based on experimental concepts, that bears little resemblance to previous UI". E.g. Ubuntu Unity, Gnome 3, Windows 8; ironically, Apple currently offers the most conservative and predictable desktop UI among currently-shipping OSes.
This doesn't really relate to the state-vs.-action question directly, except that I thing both may be related to a current tendency to emphasize visual aesthetics over functional consistency.
The reason I've chosen this is that the actual button is changing its state (e.g. other toggles merely slide a box left or right with no color or label updates). This ultimately reflects the design principle of giving the user feedback. Clicking the toggle noticeably shows a change in state.
There's also some affordance in the design because of the coloring. This isn't perfect (as acknowledged in the comment about color blindness below), but it solves enough of the problem to be obvious. No interface is 100% perfect for every user, every test case, or extreme.
Here you have 3 buttons, so it's easy to know which one is selected, but he's talking about when this is used for two different views ("often the choice is not between turning a specific feature on or off, but between two different view, modes or whatever"), and when the styling makes it hard to know which one is "pressed".
Actually, the styling in the linked screenshot is not fantastic in that regard. If it had only two buttons, you would have to assume that the one that doesn't match the surrounding bar is the one that is not selected, but if you remove the bar, or change its color, you're out of luck.