Yeah, the consensus position was originally to remove, hopefully sometime after two years, so your impression was not wrong! What I don’t think was communicated very well was: removal requires its own RFC and the result of that RFC can certainly be “not removing, just perpetually deprecated”.
Excellent, thank you! Just to make sure though, it sounds like you’re comfortable with the deprecation but only so long as there’s sufficiently clear communication that deprecation means “discourage use of the feature, it might be removed in the future”. Do I have that right?
If so, then I think what we should do is:
- Update the release note to say:
- The ``-Ofast`` command-line option has been deprecated. This option both
enables the ``-O3`` optimization-level, as well as enabling <ins>other
options, including</ins> non-standard ``-ffast-math`` behaviors. As such,
it is somewhat misleading as an "optimization level". Users are
advised to switch to ``-O3 -ffast-math <ins>-fstrict-aliasing</ins>``
<del>if the use of non-standard math behavior is intended</del>
<ins>to retain the previous behavior</ins>, and ``-O3`` otherwise.
**Note**: there is no firm date for removal of the option; its
use is discouraged and the option may or may not be removed
in the future.</ins> See
`RFC <https://discourse.llvm.org/t/rfc-deprecate-ofast/78687>`_
for details.
- Update the diagnostic message to say:
"argument '-Ofast' is deprecated; use '-O3 -ffast-math <ins>-fstrict-aliasing</ins>' "
"for the same behavior, or '-O3' to enable only conforming optimizations">,
- Remove the diagnostic for flang in light of [RFC] Deprecate Ofast in Flang; this RFC was only ever about Clang, the Flang community should be free to make their own decisions in their own time.
- Write some documentation for our optimization levels, and include more information in the entry for
-Ofast. (Because we have no existing documentation for any optimization levels, this is a “nice to have”, not a requirement to be completed before we can ship.)
WDYT?
No worries at all! I was actually thinking over the weekend about whether to fork the discussion or not, so you weren’t alone in that idea. 
Sort of, but not a change in behavior we are willing to gate decisions on. Otherwise, it would be incredibly onerous to ever introduce a new diagnostic because any new diagnostic, even ones that are off-by-default, could potentially cause the program to not compile. Users who use -Werror are effectively opting in to having compiler upgrades be more disruptive but with the benefit of trivially discovering new warning behaviors after the upgrade.