Ah, thanks for the review @twirl. I can see how we didn't exactly connect the dots here.

The idea of the proposal is that this mechanism is used for *all* data. No longer do we have arbitrary "temporary" and "persistent" buckets, which are divided by storage type---but instead, the app decides what's important, by deciding what to not delete when asked to free up space. That is, the proposal is not just touching on caches and uncritical data---it is saying that all data should be treated this way, and it is the app's job to react to space pressure and thus communicate which data is critical and which can be considered deletable cache.

As part of that, I included one sentence (perhaps you missed it) saying "new APIs will be necessary for determining how much space storage takes." With such APIs, you'll be able to say "the user agent needs 5 mb back, caches A, B, C, and D are taking 1, 4, 3, and 2 MB, let me delete caches C and D and leave A and B alone." Or if the user agent needs 15 mb back, you can say "eek, the only way to free up the extra 5 MB is to delete 5 MB of critical data; I refuse!" (so the user agent can perhaps communicate "this app is unable to free up space; would you like to remove it completely?" or it can try to ask other apps for more space.)

After writing this, I feel that examples of the kind I gave in the last paragraph would probably be the most helpful thing to add. What do you think?