a small study of "deprecate"

[monarch_dodra]

There is some talk going on right now of changing "deprecate" 
into a UDA. There are some people saying that deprecate is 
broken, and proposing some fixes (myself included). Instead of 
concentrating on how to "fix" it, and like to first study "what" 
is broken.

----
What exactly is supposed to be the lifetime of a deprecated 
function? What (default) behavior do we expect from deprecated?

**Timeline**
1. The function can be used normally.
Nothing to say here.

2. The function is *marked* for deprecation.
At this point, the user would like to be served with a warning, 
that he should consider migrating to a new function.

3. The function is fully deprecated. At this point, the user 
shouldn't be using it anymore, but if he really really wants to, 
he should be able to.

4. The function is blasted out of existenc.
----

The problem, IMO, comes from the fact that we actually have no 
way to implement "2". Because of this, there is a major gap in 
our deprecation process.

There is a proposal for "deprecate" to only do a warning. If we 
do this though, what actually happens is that we trade our "3" 
for "2", and we don't have a step were the user should *really* 
stop using the function. Just "that's fine, you can use me, here 
is a warning" to "too late! I don't even exist anymore!"

--------
At this point, I have no solution to propose, but I think I have 
analyzed the root of the problem: "deprecate" is a two-phase 
function: "Fine, you can use me no problem whatsoever" to "too 
late, I'm deprecated! (or even gone)".

The conclusion is that anything short of a "3-state solution" is 
bound to failure. We need a way to tell apart "2" from "3". 
Period.

I'm not going to propose a solution in this post, but I think 
this is a good starting point for more discussion. Thoughts?