Maybe you're kidding but I'm not sure that's really how it works. I'm sure they will do as many updates as necessary prior to a 1.0 regardless of current numbering.
Now that I've had time to check out the update in depth, I can say that this update actually affects my project in a huge way. It'll require refactoring probably around 500 of lines of code because of the elimination of {{#isolate}, {{#constant}} and preserve-inputs, and the new template.rendered functionality.
I'm looking forward to a more stable API. I think a lot of things are solidified by this 0.8.0 release, but working up to it I've had to deal with a lot of upstream changes that forced me to refactor a lot of code. Of course, its all in the name of progress and the Meteor community is super helpful and friendly, so no big whoop.
The last major hurdle for 1.0 (as I understand it) is final integration work with Atmosphere and updates to the package management system. While this is no small feat, it is far less of an engineering hurdle than either Blaze or the opLog tailing which was implemented in 0.7.0.
I'm looking forward to each template having its own local reactive state so that I can get away from storing everything in session variables, which are global.
Without this feature, it's hard (or harder than it should be) to create reusable user interface code.