Chrome's poking at defaults on a few fronts right now (`document.domain` deprecation and
https://wicg.github.io/private-network-access/ come to mind), and it's slow-going. We need to understand the impact of each change on the masses of developers who can't reasonably be expected to be paying attention to blink-dev@, and we need to ensure that we support them through shifts in browser support for behavior they rely upon.

https://deprecate.it/ has some of the metrics I'm tracking. They're basically all too high. :/

@blinkygal @AlesandroOrtiz @mikewest Seems like there might be multiple options here with very different tradeoffs, such as different options for what we're fixing:
- versioning to fix "everything we think is a mistake"
- versioning to fix a few very critical things (e.g., a few security defaults)

Then there's the question of what you don't get if you don't opt in to the new thing, e.g.:
- don't get all new features
- just get the "mistakes" fixed
- etc.

@blinkygal @AlesandroOrtiz @mikewest

Some folks at Mozilla tried to push for this with "you only get new features if you're HTTPS". It didn't really go very far, and got a *lot* of pushback.

Also, some of these options (especially "fix lots of mistakes") have pretty high costs to implement interoperably and properly test in WPT, etc.

@dbaron @blinkygal @AlesandroOrtiz We had a short conversation around the general topic of versioning in WebAppSec a ~month ago: https://github.com/w3c/webappsec/blob/main/meetings/2023/2023-03-15-minutes.md#linked-on-or-after. TL;DR: general versioning that bundles unrelated changes isn't something folks see as consistent with the web's philosophy.

Something opt-in like https://github.com/mikewest/baseline-header might be a reasonable (though low-reward) start. Ideally, we'll be able to harden `[SecureContext]` a la https://github.com/mikewest/securer-contexts, but that still requires long deprecations.