Yes and no!

I am familiar with the problem with caniuse's Chrome for Android data. The issue is filed here. Fyrd/caniuse#3518

compute-keystone-release-dates.mjs completely ignores and_chr for the purposes of computing the keystone release dates. https://github.com/dfabulich/baseline-calculator/blob/main/compute-keystone-release-dates.mjs#L59 Without that line, we'd compute that all of the keystone release dates are the release date of and_chr 113 on May 2, which is obviously wrong.

But we do use and_chr data for these purposes:

• When deciding whether a feature is available in all major browsers (i.e. whether the feature is "Baselineable") we do use and_chr for that. Otherwise, we would treat https://caniuse.com/input-file-multiple as Baselineable, but, in fact, it's not supported in and_chr, so we don't count it.
• We also include and_chr in the market share calculations. i.e. if a feature has 80% share because it's supported in Chrome for Desktop and Android, we do count that. This will systematically overestimate the market share of features that have non-trivial share in older versions of Chrome.

For example: https://caniuse.com/dialog Caniuse says that dialog is at 94.18% share today, but that's an overestimate, because it treats all "Chrome for Android" as v113, but we know that at least 5% of the 40 points of "Chrome for Android" share is on an older version of Chrome. (We don't know how old, but we know at least not v113.) So Dialog might really be closer to 93% market share instead. In the worst case, it might be as low as 92% share.

But there is a partial mitigation in place: although the current HEAD revision does not include accurate historical data about and_chr, we're measuring historical data by checking out old revisions of data.json, and I those old revisions are accurate about the then-current version of and_chr as it was at the time. (But they were wrong even then about then-obsolete versions of Chrome.)

With this mitigation in place, I think the data is "good enough" for our purposes. This calculation is meant to be an approximation in any case, and I don't think those subtle differences will fundamentally alter the question I'm asking, which is: how long do we have to wait for 80% of features to reach 95% market share?

I argue that it's four years, and maybe we should really wait 4.5 years, if only we had access to real data for and_chr, but for some features you'd really have to wait seven or eight years, and for some features just two years is enough.

The alternative would be to entirely exclude and_chr from market share calculations. To do that, I'd have to disregard the top-line usage_perc_y number for each feature, and calculate it by hand based on all of the other browsers. But this would wildly exaggerate the relative market share of "weird" old browsers like IE, Opera Mini, and UC Browser. Fully excluding Chrome for Android would imply that Opera Mini is, itself, more than 1% of market share, which it isn't, and shouldn't be.

But there is a partial mitigation in place: although the current HEAD revision does not include accurate historical data about and_chr, we're measuring historical data by checking out old revisions of data.json, and I those old revisions are accurate about the then-current version of and_chr as it was at the time. (But they were wrong even then about then-obsolete versions of Chrome.)

Cool!

I argue that it's four years, and maybe we should really wait 4.5 years,

This matches my data, so that seems correct.

Good to close 🙇