My proposal above would allow doing that using the existing deprecated-removed directive (by adding the ability to specify the removal version as notplanned, and other defined values if desired, as well as extra useful optional metadata like a deprecation reason, one of which could be, e.g., security).
I’m slow-burn working on tooling that will parse this statically out of the docs, but as a more immediate option it should be pretty straightforward to have the existing directive save each entry to a central dict and output that during the docs build as JSON and CSV. This takes maximal advantage of what we have already and minimizes unnecessary churn and manual effort in making docs deprecations and key information about them (API affected, deprecation version, removal version/plans, plus reason and any other optional metadata we add) easily ingestable by tools, and with a bit more work could even be output into a human-readable table on a page of the docs themselves, as well as in the current sections of the What’s New (Deprecated, Pending Removal, Removed).