The `pushsubscriptionchange` event ergonomics have improved quite a bit in https://github.com/w3c/push-api/pull/234. Currently, we fire a simple extendable event, and leave re-subscribing (and retrying, if the push server is unavailable) entirely up to the service worker. Additionally, there's no way for a worker to discover that it lost a subscription, for example, because the background message quota was exceeded, or the user cleared site settings. Finally, there's no way for the worker to retrieve the old subscription: it's already gone by the time we fire `pushsubscriptionchange`. The spec now says we should resubscribe automatically, and pass the old and new subscriptions (`null` if we couldn't fetch the old subscription or create a new one because the user revoked permission) to the event handler. We'll need to implement the new `PushSubscriptionChangeEvent` interface, figure out how to store and pass the old subscription to the event handler, and make sure we keep old subscriptions around until we've resubscribed. We'll also need to do something for chrome-only subscriptions...maybe just passing the WebIDL `PushSubscription` interfaces around would work?