It's not clear to new core contributors that CMI is now a part of core, and that we're in the process of migrating to config and state. We should mark the variable_* functions as @depreciated to try and head off patches being rolled still using those functions.

Comments

We do not support any @deprecated tag at this time in the API module, so this is not the right way to mark a function as deprecated (we don't have a standard way to do this actually). Even if we did have @deprecated as a tag, it would not include a paragraph of explanation.

I'm also putting this into the config component for now because I won't commit a patch marking these as deprecated without the approval of the component maintainers... why not just remove the functions when they're supposed to be removed? What's the schedule for that?

The proposed code here is scheduled for *total* removal before D8 gets released, so I don't think we're blocked on that policy issue, or need to be strict in how exactly the phpDoc should look like. It is a very very temporary measure only, as an attempt to prevent developers from introducing new variables in D8 code.

On that other issue, several people commenting made the point that this was actually the normal circumstance -- temporarily marking things as deprecated during the dev cycle. So, I'm not sure that's a compelling argument for not following the standard. If we even need a standard (which I questioned on that other issue) then it applies to this case as the main use for @deprecated...