MeeGo

I honestly haven't investigated Meego's full power management implementation, but the easiest way to implement management of this would be to use the new cgroup timer slack mechanism. You'd still require some sort of userspace-level wakelock implementation, but when no userspace locks are held you extend the timer slack for all untrusted applications out to infinity (or as close as possible). Events will still be implemented in a timely manner, but once a task's finished handling it and hits a select or timer it won't be scheduled again until another event hits.

This ought to handle the case that wakelocks are designed to handle, which is that an aggressive suspend implementation leaves you open to races between your suspend policy and event delivery. It also avoids the problem of using a freezer cgroup, where not all events are delivered through a framework so you still have races.

The main difference between wakelocks and this is that truly pathological applications still hurt you (if something's in a tight loop it'll still be scheduled), but also you have to trust your underlying layers to be correct (ie, never to wake up unless event delivery occurs). Running the current Android implementation in such an environment would result in a measurable decrease in battery life. But if your framework's been designed with this in mind, it means you get the benefits of aggressive suspend without the overhead of maintaining semi-fragile kernel modifications (some of which certainly stand no chance of going upstream).

There's no fundamental reason to think that the Android approach involved less engineering effort than Nokia's, and the long-term outcome should have been pretty similar in terms of ideal-case battery life. My experience is that it's not difficult to ensure that your core code is event driven provided that that's a design goal from the outset. So I don't think this distinction is what led to Nokia ending up so far behind schedule. There's probably more straightforward reasons for that.