###Update: I am unable to reproduce the case of interactive browsing affecting app quota. And will concede that the failures that prompted this post were likely far edge cases.
The remaining issue of a badly behaved app failing and thus inducing a browsing DOS is not a bug in the throttle, simply a consequence of running a badly behaved (designed) app.
It was the other way around that concerned me i.e. interactive browsing eating app quota and inducing an all-around DOS.
I am not yet completely convinced that this is not a possibility, but until the throttle rate issues is cleared up, it is near impossible to write a test that can get reproduce what is admittedly and edge case (i hope).
This is a very serious issue.
The implication is that every app written against the API must warn the user not to view any Stack Exchange site while using (or 5 seconds before or after starting) the app or complete app and browsing failure could result.
Given the 'if you violate the throttle you, the response is undefined as are the consequences which could include being banned for an indeterminant period of time' (paraphrased, correct me if I am wrong) specification, this is best avoided.
Some have gone to extraordinary lengths to comply with the published throttle guidance, which I am not sure is yet accurate, and to lump the end-user's browsing activity in with the throttle quota is an impossible criteria to manage.
This behaviour was introduced with the new throttle and I can only assume that this is an oversight and hope that it will be resolved.
The obvious solution is to separate http://api.xxxx and http://xxxx requests from each IP into distinct quota buckets.