Reading through these complaints, all of them seem to be your fault. It’s akin to the bike fall meme [1].
Firstly, you complain of a third-party dependency being broken in a preview build of Safari, and that you had went on holiday the week the stable version was published, meaning you couldn’t guarantee the problem was fixed in the stable release. Plainly, that’s an organisational problem on your end—the Safari team fixed the problem on their end. I’ll come back to your complaints re. release schedules.
Your second complaint is, in your own words, “we accidentally relied on a Chrome bug that meant our Service Worker was broken in Safari 16.4.” You go on to rehash your initial complaint, which is that Apple doesn’t publish a release schedule for Safari. I don’t inherently disagree with this complaint at face value.
Finally you move on to your third complaint, but to me it seems like yet another problem on your end. You made the observation that a given feature was supported and made the assumption that it was supported fully, with no other logic in place to test functionality or fallback to another rendering method. By your own admission again: “We detected OffscreenCanvas merely by seeing if it was defined. I never expected a browser to ship it with some contexts but not others - I assumed it would have parity with the standard canvas element.” I can understand the frustration and panic of being caught out here, but the pitfall is in your application logic. Your arguments afterwards with regard to supporting existing content are well said, but don’t generalise in this case. Just because something broke for you doesn’t mean everyone made the same flawed assumptions you did.
You then go on to list a random assortment of historic instances of Safari having flaws, as if that isn’t true of all browsers across the board.
[1] https://knowyourmeme.com/memes/baton-roue