Mostly looking okay, but you have many missing references.

Actually, no not okay, _api does not expose any of the deprecation machinery directly like that.

Why not just from _api.deprecation import deprecated? Instead of just making _api the new catch-all name space for helper functions?

Don't really have a strong opinion here but I figure you've given it some thought so wanted to know.

I'm a bit paranoid by now concerning semi-public API. Importing deprecated leaks the name into the module namespace. - I know that other imports do that as well, but we can prevent in this case quite easily.

Also, I don't want to import the specific functions (check_in_List, warn_deprecated, make_keyword_only, rename_parameter, ...) and remove the imports when they expire. That's a big back and forth adapting of the imports. One could even consider inlining the deprecation module into _api, but for now I'd leave it as a sub module.

Furthermore, I like the _api prefix indicating the context. For example it makes it immediately clear, that _api.check_in_list() is some sort of standard function within our framework and not only a local helper function check_in_list().