In the standards world, there are generally just the two states: “normal” and “deprecated”. Deprecated features generally do get removed from future standards, sometimes in the next revision, sometimes in the revision following. There isn’t always a “better way” added to replace it. In the register example I gave, compilers just stopped needing to be given that hint.
In the Java world, deprecated is more for library authors to mark an API as “to be avoided” / “superseded” with a better way – a different signature of the same function is most common. Whether a deprecated feature is removed later is up to the library author. Java’s evolution is glacial so standard library functions marked deprecated tend to stay around for a very long time.
In the Clojure world, deprecated is used more in the standards sense, by both the language designers and library authors. Deprecated things do tend to go away (eventually).
Coming back to CFML / Lucee: “deprecating” createObject() in CFML is a bit silly since it’s just not going away until Adobe decide it is (which is likely never given their obsession with backward compatibility). For Lucee, you can just go right ahead and remove it – for the Lucee language, you can simply require folks do it a different way.
I don’t really see any point in “avoid” / “superseded” to be honest – that was more a suggestion to avoid the charged meaning of “deprecate” in a context where LAS do not intend to remove a feature (because compatibility).
@micstriit seems to want a way to label features as “undesirable” but without the intent to remove. If that’s the case, then “deprecate” is the wrong term, in my opinion.