Resolved the merge conflict (caused by #13936) and added Webview Android versions from that PR to the eventName_event entries.

Here are the differences:

api.Texttrack.cuechange_event

"opera": {
    "version_added": "15"
},
"opera_android": {
    "version_added": "14"
},
"safari": {
    "version_added": "7"
},
"safari_ios": {
    "version_added": "7"
},
"webview_android": {
    "version_added": "≤37"
}

api.Texttrack.oncuechange

"opera": {
    "version_added": "≤12.1"
},
"opera_android": {
    "version_added": "≤12.1"
},
"safari": {
    "version_added": "6"
},
"safari_ios": {
    "version_added": "8"
},
"webview_android": {
    "version_added": "4.4"
}

api.TextTrackList.removetrack_event

  "opera": {
    "version_added": "20"
  },
  "opera_android": {
    "version_added": "20"
  },

api.TextTrackList.onremovetrack

  "opera": [
    {
      "version_added": "20"
    },
    {
      "version_added": "≤12.1",
      "version_removed": "15"
    }
  ],
  "opera_android": [
    {
      "version_added": "20"
    },
    {
      "version_added": "≤12.1",
      "version_removed": "14"
    }
  ],

My assumption is that the onremovetrack and the oncuechange entries are more correct because these were updated by the collector.

Yes, I'd take the onremovetrack data for Opera.

For "cuechange_event", I think this would be a good guess that's fairly consistent with the other data:

"opera": {
    "version_added": "≤12.1"
},
"opera_android": {
    "version_added": "≤12.1"
},
"safari": {
    "version_added": "6"
},
"safari_ios": {
    "version_added": "7"
},
"webview_android": {
    "version_added": "4.4"
}

Another thing here is api.GlobalEventHandlers.oncuechange.

My guess would be to remove this data as it is captured in api.TextTrack.cuechange_event and api.HTMLTrackElement.cuechange_event.

Not sure where to redirect https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/oncuechange to. Either to https://developer.mozilla.org/en-US/docs/Web/API/TextTrack/cuechange_event or to https://developer.mozilla.org/en-US/docs/Web/API/HTMLTrackElement/cuechange_event

Not sure where to redirect https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/oncuechange to. Either to https://developer.mozilla.org/en-US/docs/Web/API/TextTrack/cuechange_event or to https://developer.mozilla.org/en-US/docs/Web/API/HTMLTrackElement/cuechange_event

I redirected to TextTrack. Appreciate a look at the content change, too: mdn/content#12684

Will remove api.GlobalEventHandlers.oncuechange here then, too.

I made the mistake of checking if the two remaining "cuechange_event" entries on TextTrack and HTMLTrackElement now seem to make sense together. Of course there are issues.

A trivial issue is that a link to https://html.spec.whatwg.org/multipage/webappapis.html#handler-oncuechange is missing.

https://trac.webkit.org/changeset/100064/webkit introduced the two events in WebKit, so the versions for Safari should match, but they don't. The data for TextTrack is largely Safari/iOS 6/7, but for HTMLTrackElement it's 6/6 or 7/7. Which is correct?

I doubt the data for Opera is correct, and would suggest setting it to "12" like most of HTMLTrackElement.

There are also differences in the IE and Edge data that I haven't researched, but I wouldn't be surprised if it's wrong.

Also, should we capture that the oncuechange attribute for HTMLTrackElement was added much later than the event itself was supported? That happened in https://trac.webkit.org/changeset/204729/webkit.

Thanks for your detailed view. Unfortunately I don't know all the answers.

A trivial issue is that a link to https://html.spec.whatwg.org/multipage/webappapis.html#handler-oncuechange is missing.

Done.

I doubt the data for Opera is correct, and would suggest setting it to "12" like most of HTMLTrackElement.

Done.

Also, should we capture that the oncuechange attribute for HTMLTrackElement was added much later than the event itself was supported? That happened in https://trac.webkit.org/changeset/204729/webkit.

I've added a range to show partial support. The wording is per our guideline: https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines.md#dom-events-eventname_event

For the issues with IE support and Safari versions, I don't know how to resolve the issues you found. You could file it as a new issue and we land this to continue refactoring other event data?

If this is approved, it can be merged. The content work got merged in mdn/content#12688 and mdn/content#12684