If suggestions are to be made i'd rather have them be made by the designers of the APIs/languages, especially those are have been around for some time and have developed better approaches for doing things already possible previously but in a worse way.

For example imagine you have an API that Foos Stuff, the initial version could have been FooStuff but it turned out that after 10 years of active use, the approach was slow for modern use cases and the only way to improve it was to change the API to BeginStuffFooing, ProcessStuffFooing and FinishStuffFooing but still keep the original FooStuff for backwards compatibility.

After 10 years of use, an AI-driven approach that data mines existing codebases (especially popular codebases that are more likely to be mature/old codebases) will be more likely to use FooStuff than Begin/Process/FinishStuffFooing, thus people will be steered towards FooStuff instead of the better approach.

Something that is driven explicitly by the API designer can start recommending Begin/Process/FinishStuffFooing from the moment it is available and recommend against introducing FooStuff in new code (it could even show up a tooltip or whatever with a "here is how to use the new approach if you already know the old approach" link).

Isn't that what the Obsolete attribute is for? Or similar attribute/test driven enforcement of migration to new approaches.

It mines your own codebase, not public ones.

Yes, but it isn't enough information and TBH i do not think that at the language level you can have something that will provide a good enough UX (but then again i'm not in favor of Javadoc-style comments and i believe documentation should lie outside of the source code).

As far as I’m aware (caveat: my knowledge may be slightly out of date here), none of the older .NET async patterns - APM, event based async - have been marked obsolete despite the task based versions being preferable for a long time.