The list goes on and on.
And yes. Despite these being minor version updates, stuff will break if you go from, say, version 2.9 to version 2.11.
I can tell you that virtually everything I’ve used, from networking (legacy to VPC) to storage (Cloud SQL v1 to v2) to Firebase (now Firestore with a totally different API) to App Engine (don’t even get me started) to Cloud Endpoints to... I dunno, _everything_, has forced me to rewrite it all after at most 2–3 years.
People assumed that because we made a new database we were killing the older one, but that was never true.
But also idk what else you'd want them to say "the thing you're taking shit isn't deprecated" seems like an important response to "you mishandled this deprecation".
Personally, I think most of them seem quite sensible. Having a 'support everything forever' approach is obviously going to impose a huge burden on the teams who maintain this stuff which is then going to limit the ability to make anything better. The depreciation notices generally seem pretty good (12-15 months notice by the looks of it, sometimes followed by degraded functionality rather than complete removal of the feature).
And yet AWS is doing just that while innovating at the same time.
[1] "Depreciate" is something else.
Come to think of it, the Channels API shut down was a bit of a nuisance. But it never worked all that well, and deprecation seemed like a reasonable move to me.
Here's a detailed list[1].
There's a reason that people trust Amazon with their compute, and that's because in regards to their technology they're trustworthy.
Example: https://cloud.google.com/stackdriver/docs/deprecations