This dog isn't ready to hunt yet, Steve. The right way to analyze this is to turn to engineering standards and apply them to the advertised functionality and quality statements.
Then one has to ask: Does it pass all the functional test requirements? Does it pass all the quality test requirements?
Based on user feedback in these forums and blogs and other forums, and even considering some problems that are clearly in the 'failed to read and understand the manual', 'failed to read and understand the advertised features', and 'failed to read and understand the promised functionality', and not the very least, 'failed to understand the purpose of the technology' and 'failed to appreciate my responsibility', there is still a lot of broken stuff left.
Really krufty stuff to do with documentation, Boot camp integration failures, troubleshooting and diagnostics, recovering from self-inflicted stupidity, defining roles and responsibilities (blame one or more of: Microsoft (Windows XP/Vista), Apple (Boot camp), Linux d`jour (crappy products), hardware vendors (crappy USB compliance), Parallels (networking, USB problems, endless Boot camp errors, documentation, documentation, did I mention documentation?)).
If you look at this from a project manager's perspective, particularly in an audit role, you just have to scratch your head and wonder what the hell they're thinking. I really don't want to see a better polished version of this apple become the next release because it means to get what I want I have to buy it again as a subsequent release and I'm just not going to do that. I expect the ones I bought to do what they said they would do. Even features I have no intention to use because it's not about me. It's about their promises.
