Maybe we're talking about two different things? To me, once you add a new feature intended to replace an old one, the old feature should be deprecated and should eventually be removed. Even if you can use AssetBundles, there's no reason you ever should because they've been superseded.
I've always thought that that is deprecation, but I could see your argument that it's not.
Fortunately I haven't had to deal with the officially deprecated features without a clear replacement. I can imagine that would be very frustrating.
> Even if you can use AssetBundles, there's no reason you ever should because they've been superseded.
You might have to use a superseded feature because you're maintaining old code. If Unity cares about backwards compatibility (admittedly, I'm not convinced they do), they need to keep supporting and documenting the old features even as they nudge you away from them.
Sure, but if that's the case, you should really be pushing new developers away from using the old thing and towards the new thing. Mark it obsolete in the editor. Update your docstrings to point towards the new thing. Maybe even give me a warning in my console if it's really serious.
I can see that's a gray area (you are kinda deprecating it by doing this) but the strict definition of deprecation probably involves a pledge to remove that feature in a certain timeframe.
I'd be much happier to bitch about the stuff Unity has officially deprecated without having a good timetable for a replacement (Networking, Real-time GI) or done a terrible job of communicating the situation (Steam VR is "not officially supported" sounded pretty apocalyptic whereas it turned out to be not quite so bad - Valve had taken over responsibility for support and their solution was released to beta with a month of the doom and gloom corporate-speak announcement)