Backing @corgrath here - nobody here is jumping the gun, actually.
The order of action when planning to deprecate something is to provide an alternative first, and then [provided it’s tested, stable, etc] deprecate old endpoints in favour of new ones, not the other way around…
I’m curious what the idea behind this decision is, because this is the first time in a while I’ve seen something deprecated before an alternative is ready, especially that there’s nothing wrong with v5 from the looks of it. Why “kill” (it’s not dead yet, but you get the idea) a perfectly fine API in favour of something that’s not even finished…???