Well, maybe we need a term like "circumstantial SARGability", to indicate that edge cases can be found where "normal SARGability" fails but a clever DBA can get seeks to happen anyway.

Would cover the situation you posed, without necessarily reducing the usefulness of the term in training general query writing skills.

The most important aspect of SARGability as a term is being able to use it in training people. That means keeping it simple, and letting them know that, "For most applications you will build using T-SQL, it's important to keep function-use out of Where clauses and Join math, because of ..." and go from there. As with everything databases, there are caveats, loopholes, "it depends", and "most of the time"s.

The main reason I want to keep the general term closely tied to writing queries, instead of related to specific object properties or data properties, is because that keeps it most useful in teaching query-writing.

Keeping it that way also helps with teaching database architecture. "In order to best support the SARGable queries your devs will be writing, you should design tables with the following in mind ..." That kind of thing.

More advanced querying techniques and architectural techniques will usual be done by people who understand the rules well enough to know when to violate them. At least, that's the hope. 🙂