You want to call /f$/ something that's anchored, but /\s+$/ can't be called anchored, because of what the optimizer can or cannot?

I don't think anyone will benefit if you let jargon depend on the current state of the optimizer. That would only be confusing - and it will expose the implementation. The meaning of /\s+$/ doesn't change whether the optimizer catches it or not. And if neither the meaning, nor the syntax changes, the name shouldn't change either.

IMO, /\s+$/ is anchored, because it will only match if there's whitespace in front of the end of the string - and it will match that whitespace. How the regex engine comes to that conclusion doesn't matter.

Your example as an example of anchoring being a misleading term is itself misleading. It's exactly doing what it means: it makes sure that what needs to be matched ends at the end of the line. Remove the anchor, and it'll match something else (the empty string). If the problem is in the anchoring, then it's because you don't have an anchor at the beginning of your match. Not that there's an easy anchor for that - never the less, the anchor at the end of the regex is correct. With a correct name. Which also explains why you aren't seeing replies "you aren't anchoring your regex to the end of the string". Because you are.