So, I think for future debugging, the question of "why a system woke up" is quite useful. Its possible something similar to the /proc/timers_list would be wanted so analisys applications similar to power-top can monitor why we are waking up.
But I think "why a system woke up" question is probably less important then the decision of "when should it go back to sleep?".
Currently suspend is initiated by userland. So its outside of the kernel's scope for the moment.
But I can see one potential issue where maybe there's a system that will suspend after 15 minutes of X-idle. A alarm timer fires, and then wakes the system to do some work, but that work takes longer then 15 minutes, so the work gets cut off when the system suspends again.
You could have the application contact the power-management daemon and inhibit suspend while the critical work was being done (much like how slideshow or movie applications do this). This would probably work for the most part, but there are still some races between the wakeup and the userland inhibit message being sent.
And indeed, as Paul mentioned there are a number of different approaches being worked with here, with wakelocks being the most contentious, but also most complete.