Absolutely. Here's a few examples, though I could produce a hundred more:

AssetBundles. Not marked as obsolete. Not marked as deprecated. Unity docs look fine, with no references to anything else you should do: https://docs.unity3d.com/ScriptReference/AssetBundle.html. They are in fact obsolete anyways. See here: https://learn.unity.com/tutorial/assets-resources-and-assetb... "this tutorial has now been deprecated. We now recommend using Addressables for your projects"

EditorUtility.SetDirty(). Rider says "Marks target object as dirty. (Only suitable for non-scene objects)" and it's not marked obsolete or deprecated. Seems fine, right? Nope, it's been deprecated since 5.3. To their credit, the full Unity docs do reference this, but who is going to consult Unity docs for literally every Unity function they ever use, in their entire project? It should be right in the IDE. Better yet, the function shouldn't even exist! Unity 5.3 came out over 5 years ago!

Hmmmm. Is it possible that a tutorial is deprecated without the actual feature itself being deprecated? i.e. there's no intent to get rid of AssetBundles in the near future but they don't want people who are just starting out to go down that path?

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)

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.

The 'Addressables' are a abstraction layer on TOP of AssetBundles. AssetBundles aren't deprecated.

Honestly most of the criticisms you've gave are you not understanding how something works - like GetComponent. I do agree with you on 'null' though! And how Unity uses it. I think that decision came from them trying to make it more beginner friendly to deal with destroyed/removed objects when it first started - then they had to live with it

If X is built on top of Y, and I should generally be using X, then the docs for Y should absolutely say that. Burying that away in some hard-to-find tutorial is not good practice. We could argue for a while over the exact semantic meaning of 'deprecate' and whether Y is truly deprecated if 99% of the time when you use it you should really be using X instead. But I'd hope that we can both agree on the central point of my argument here, which is that in Unity it's often incredibly difficult to figure out which of 5 vaguely-similar-looking APIs you should be using, and it's a bad sign when the best source of info is a "coming soon!" message on an out-of-date tutorial not even linked from the documentation.

Perhaps you should explain how I've misunderstood GetComponent.

The whole purpose of using 'GetComponent' in code is to get the component reference at runtime. Saying it's a problem that it doesn't statically verify it exists, doesn't make any sense

I understand that GetComponent is a runtime lookup, and what I'm arguing is that Unity made the wrong choice. Runtime lookups lead to more bugs. They lead to slower code.

The best practices that have sprouted up around GetComponent say "Use GetComponent<> only in Awake(), and don't use AddComponent or RemoveComponent at all." But once you start following all these best practices, you've lost all the benefits of having GetComponent be dynamic in the first place. So just enforce it at a code level, and give me the benefits of static typechecking and compile time errors when I screw things up.