The proposed meaning of the machine-readable version number is problematic.

All uses of `@deprecated` tags I'm aware of are using the machine-readable version to identify the version in which code has been _marked_ as deprecated.

→ Essentially having a similar meaning as `@since`.

The version in which a resource is _scheduled_ for removal (not guaranteed) is normally mentioned in the description.

The suggested interpretation of the machine-readable version value is not really compatible for larger FOSS projects, which rely on volunteers to clean up obsolete legacy code.  A FOSS project can only realistically state in which version a resource has been deprecated, but it's not reliably possible to state when exactly a contributor will spare the time to remove a particular piece of deprecated code.

Although I could understand the idea that closed-source code bases might have a more strict management and organization behind them, the same can be applied to that context, too, because original plans and current goals/requirements do diverge very often.

The meaning of the specified machine-readable version should be the version in which the code has been marked as deprecated.

...and because the given machine-readable version number must be a semantic version number, some additional natural/common sense can be applied:

* `@deprecated 2.0.0`  
  By design and by definition of all available versioning standards, the stated version number naturally means that this code can only be removed in the next **major** release.  
  If it still exists in the next major, then it can only be removed in the second to next major.
* `@deprecated 2.x`  
  OTOH, this tag was likely added during development of `2.x` and it implies that the code is a temporary legacy/BC shim and can vanish at any point in time.  
  If it doesn't vanish prior to the stable release, then its removal will have to wait for the next major dev cycle.

In an ideal world, of course, the `@deprecated` tag would support _two_ machine-readable values; i.e., (1) the version it _was_ deprecated, and optionally (2) the version in which it is _scheduled_ for removal:

```
@deprecated 2.0.0 3.0.0
  No need to explain this at all.  Machine-readable by design.
```