I don't think users should be expected to hack about inside OS defined scripts to get decent behaviour.
I've never come across this being a problem before. If you feel strongly about, file a bug.
The most IsBadXXXPtr can possibly tell you is that it was valid/invalid at some arbitrary point in the past.So absolutely any code which ever uses foo still has to call it defensively and handle the situation in which it was a bad pointer. Thus making the IsBadXXXPtr call entirely redundant.
Knowing that it used to be valid is still better than nothing. And any code which calls foo doesn't have to code defensively if the contract is anyone who calls SetCallbackFunction() must set a valid function (an example of this is the SetUnhandledExceptionCallback function). If that function used to be valid but no longer is, well all bets are off - the guy who unloaded the function could just have easilly unloaded all of the exectauble code in the process and then you'd definitely crash.
If you're trying to prevent people who can run arbitrary code in your process from being able to crash it, you're going to lose, and the IsBadXXXPtr isn't going to help you. If you want to put in debug assertions to help catch errors in development (which might be your or other people's code) then this is an entirely valid programming style.
If you can hold a lock on something, then it's no longer entirely out of your control, so that's fine (just as a similar pattern on entirely private objects is). Getting a lock on something that doesn't exist (or at best whose existance is indeterminate) doesn't work though and hence we find ourselves back at the IsBadXXXPtr anti-pattern.
You never get a lock on something that might not exist. You get a lock on the container of the object, and then you query for the object. The same is true in SMB/webdav.
1) Get a connection to the share (if that fails, fail with a NO_NETWORK error)
2) Traverse as far as you can down the folder heirarchy. If you fail, return a FILE_NOT_THERE error.
3) Lock the folder. If this fails, return a LOCK_FAILED error
4) Query for the file. If this fails, unlock and return a FILE_NOT_THERE error.
5) Do something with the file. The file will be there because you have a lock on it, and when you're done release the lock.