Safari has a radically different approach to numbering to all the rest (even though it’s them that changed, not it). It’s bumping its “major” number once per year, whereas Chromium and Firefox are bumping theirs 10–12 times per year. Unless they have radically different deployment strategies, “major versions” is clearly useless as a consistent concept across browsers. But despite Safari being tied to the OS version, when you take everything together (hardware support for their OSes, OS upgrade frequency) it’s only a little different, nowhere near the 10× difference in importance of a “major version”.
All up, I say “two major versions” is obviously a completely unsuitable definition to use. It needs to treat Safari differently, e.g. “two major versions of Safari and twelve major versions of all other browsers” (which would catch Firefox ESR) or “thirteen months of browser support” (which would be less for Safari most of the time, but really, consider the deployment cadence and it’s probably not so different, though maybe you’d bump it to fourteen or fifteen months, I dunno).
Major versions isn't a useless consistent concept because it's the strategy all browser developers use to determine when major features are added (vs bug/security fixes). Which is what Baseline is for, feature adoption.
So if Safari is adding a slew of major features once per year, and Firefox 6x per year, it doesn't matter. We have a baseline of what features as developers we can now implement without worrying about which browser version supports this or that. We see the baseline, we add the feature.
Last two major versions has been utilized (unofficially) by most people through Browserlist. It's been both suitable and productive.
This is nonsense. Safari adds major features in point releases: just look through some of https://developer.apple.com/documentation/safari-release-not... and see. Some of the biggest features get held for the next “major” number bump, certainly, but most point releases include at least as much as most major number bumps in Firefox or Chromium.
In my experience, people haven’t tended to use just “last two versions” with Browserlist: IE has normally been special-cased historically, and Safari has regularly been special-cased in some way, and Safari has actually been the salvation of the “last two versions” strategy because it dragged the baseline down to a more acceptable place, where “last two versions” of only Firefox and Chromium would regularly be disastrous. It has long been a really poorly-thought-out mechanism.
The other point you’re missing is user adoption. “At least one year” for Safari is one thing, but “five weeks” for everyone else is pretty crazy when you look at actual update statistics.
The issue with Safari is that it's tied to the operating system on iOS. That's an issue with minor releases, but even more so with major releases, where you can't get Safari 16 for iOS 15. That naturally means slower uptake compared to Chrome or Firefox which will update the browser in the background seamlessly.
I'm hoping that we'll be able to identify better usage data and a better understanding of developer expectations to refine this definition.
All up, I say “two major versions” is obviously a completely unsuitable definition to use. It needs to treat Safari differently, e.g. “two major versions of Safari and twelve major versions of all other browsers” (which would catch Firefox ESR) or “thirteen months of browser support” (which would be less for Safari most of the time, but really, consider the deployment cadence and it’s probably not so different, though maybe you’d bump it to fourteen or fifteen months, I dunno).