>> Revisions, enhancements, and new development should all be treated the same: 100% coverage where possible.
>
>IBM's study on code coverage concluded that anything beyond 80% doesn't give good bang for the buck.

Well that could be specific to IBM and their willingness to support their own stuff.
Some things shouldn't be measured on "bang for buck" anyway. We've all heard of car manufacturers that trade off costs of pennies per vehicle (totalled up it gets LARGE) versus number/value of injury/death suits.
WHY do electronics manufacturers go to lengths to test their products before ship when they get a better than 98%+ passed rate?... because their name means something and is worth protecting. And because any service calls will be much simpler and more 'common'.
IF MS accepts 80% coverage as adequate (and I realize you did NOT say that) then they can only do themselves a disservice in the long run.

In any case, I hope and expect that "pride of workmanship" alone pushes the vast majority of VFP developers to test their code to as close to 100% as possible.
I agree that users will do things that one can never anticipate in testing, and that this is greatly compounded by the possibility that an app. can run on a variety of OSes, each with varying levels of maintenance applied. Not to mention (potentially) lethal combinations of apps. and services running.
But, at least in the first case above, one can always be confident that they still have a well working system in the absence of the user doing that strange untested thing. The user can still use the product - ceasing the damaging activity pending fixup to that.