My view is that FreeBSD 8 is far more coherent and complete, and just as stable, as FreeBSD 4. (FreeBSD 9.0 has a few glitches related to UFS SU+J but those are fixed in 9.1.)
As for the upcoming release schedule: The next release after 9.1 should be 8.4, early in 2013. Whether FreeBSD 8.5 ever happens is an open question; we'd like to offer major branches which live for longer than our current 5 years, but we're hobbled by some contrib code which is poorly supported upstream, so my guess is that it won't happen in the 8.x branch.
That is our view as well (that 8 is more coherent and complete, stable, etc.).
The problem is that it doesn't matter unless it has a long lifecycle with lots of minor releases.
You can't deploy on the x.0 release - a bigotry that we think is deserved given the results of 5.0 and 9.0. So you need to wait for .2 or .3 or so to be confident in the release at all. But then ... if .4 is as far as it goes, you've invested years of work and hundreds (or thousands) of thousands of dollars into just one more year of lifecycle.
So 8.4 would be a good sign, and 8.5 would be great, but we need a release that lasts for a good five years and runs up to the .10 or .11 or .12...
One of the links we just posted from that big thread (the second one, I think) is the proposal John made for picking a "long term release" every few releases and really committing both time and energy to making it last long enough so that serious investment can be made in it.
That's a two way street, btw - it's not just the ability to invest in your own processes and architecture, but the ability to invest back into FreeBSD. We've had a LOT of potential feedback and contributions that could have been made throughout 6 and 7 that just never seemed worth the time and effort given how excited everyone always is about the bleeding edge ...
As for the upcoming release schedule: The next release after 9.1 should be 8.4, early in 2013. Whether FreeBSD 8.5 ever happens is an open question; we'd like to offer major branches which live for longer than our current 5 years, but we're hobbled by some contrib code which is poorly supported upstream, so my guess is that it won't happen in the 8.x branch.