I have little doubt that you have thought this through, and for your work they are always used in an aidentical fashion and could be collapsed into a single pre

I have little doubt that you have thought this through, and for your work they are always used in an aidentical fashion and could be collapsed into a single predicate with no visible distinction between teh two use cases in the calling code. But for many applications, the semantic difference between the two drives different patterns in the calling code, and when that is the case, having an easily visible difference between the two predicates makes the code more readable and prompts people to write it more correctly. Example: What happens when the answer is "no?" For many bog-standard applications, it's a NOOP. Let's say there's a feature: You can edit a message that has already been sent. If you are wrapping that in a flag for gradual rollout or early access purposes, you wrap both the client-side edit control and the server-side API endpoint in the "can X do Edit" test, and if the answer is no, you don't show the control in the client, and you 404 the endpoint on the server. Whereas, if editing messages that have already been sent is a feature only available to a special class of users—let's say they are paying $8 a month for an orange check-mark on Hacker News—then on the client we still hide the control if our user is not authorized to edit messages. But on the server side, we typically don't want to 404 the endpoint, we want to give some semantically appropriate response such as a 401 "unauthorized" status. If you use one construct for asking both FF and auth questions, it's hard to see at a glance whether the code is doing an appropriate thing with the answer. This is grossly oversimplified, but the thesis here is that yes, if you use both FFs and auth in exactly the same way, it's reasonable to consider using one way to ask the question. But the definition of "using them the same way" should also include what you do with the answer. In your case, you very likely always do exactly the same thing with the answer regardless of whether the answer is derived from FFs or auth. But for those who do different things depending on which question they're answering, I suggest having different ways of asking the questions provides better affordances for writing and maintaining the code.