Hmm. I'm not on the dev. team but maybe I can shed some educated guesses

1: Bob could be an engineering / product manager who is looking across multiple teams from engineering to QA to third-party developers (flash, mozilla , Skype and etc). Releases are NEVER perfect. The question is whether or not that particular release has the desired or acceptable fixes required without regressions. Rarely do they all line up and express readiness as a yes or no. Usually the answer is "it depends on what you mean by acceptable"

2a: If they knows all the problems and fixes then the answer is they'd release it
2b: If they found problems but have not isolated then its a matter of understanding how pervasive the problem is. Does it affect one component (UI causing memory lead) or is it kernel related that affects everything from memory management to browsers to the phone
2c: Once they've isolate the problem they have to reproduce it then make an guess as to what they think it will require to fix it, keeping in mind that they can't break anything else in the process.
2d: They then have to do the actual fix and then unit test and make sure that it does in fact fix what was broken and hasn't broken anything else
2e: Depending on the level of fix they may have to test everything all over again. Remember that code isn't isolated. They're not dealing with typos and misplaced semi-colons here. These may be large systemic issues that affect multiple components. A fix isn't just an isolated blob of code, but could mean a series of actions that can and will affect other pieces of code.

Just throwing out a random example. Let's say for 1.2 they made everything scroll smoother more realistic. Well in the past maybe hand gesture scrolling wasn't so good so individual app makers wrote / hacked code so that scrolling was acceptable to their app. Now that scrolling has been fixed the hack now makes the apps unusable or perform worse. The fix could be done by making changes to how the scrolling is done or it could be in the individual app. Again I want to re-iterate that I don't know the issues with 1.2 but wanted to illustrate that code is interdependent and answers aren't always clear cut.

More conjecture. One focus of this release seems to be performance related. The one thing I've found in the releases I've managed is performance related bugs are in layers. As you improve performance in one area that only shows the bottlenecks in the next, and so forth and so on. It's a good thing but this stuff takes time to sort out, there are no magic bullets. Again, just a guess.

To me anything that has taken this long means they're in a dependency nightmare or there are regressions. If for example Flash was the issue they'd just do what they did last time, disable flash and have flash update separately after. They aren't doing that because I think they are dealing with internal dependencies that affect all components. And if there are regressions. It's certainly not acceptable to start losing current functionality for a few new things.

3: How can they guarantee that they'll release this month or next without the proper timelines? For major releases usually there is a usually a beta and test window where features / bug fixes are frozen well before release. With updates like this there is feature creep and intermittent bugs which get added. Their intentions are good because the community clamors for all fixes but what results is a hairball where they probably should have done a more traditional test cycle because with the new features and major changes, this is more than just a 1.2 but maybe more like a 1.4 or 1.5 (when looking from a scale perspective). But hindsight is 20/20 right?

Or it could be some executive unilaterally decided to move half of the engineers to Meego to make that successful. Who knows.