If that is the case, it will need to be prefixed with "Show/Hide" because the verb will otherwise be wrong half the time. Alternatively, "Viewport X-Ray On/Off" which is probably a better option. But I don't think it's necessary to break consistency with its neighboring toggles and only use a verb here, because the button being a toggle is obvious enough from its own presence with the blue background when clicked.

The name of the property is what it does when it's enabled. We don't call properties Show/Hide or On/Off.

Names of properties can't be set based on assumptions on how they are used in one place in the interface, they are also used for things like quick favorites and Python API docs.

We have conventions for naming properties, they should be followed until we decide to change the conventions.

Thanks for the clarification, that reasoning makes perfect sense to me. I'm also going to change "Viewport Gizmos" to "Show Viewport Gizmos" and "Viewport Overlays" to "Show Viewport Overlays". However, for "Viewport X-Ray" it seems like we should be using "Enable" instead of "Show" because that is a mode that doesn't "show" anything, per se, but it enables a modification to what is already shown (so that the scene becomes shown using the x-ray feature).

And likewise, should I change "Snap" into "Enable Snap" and "Proportional Editing Objects" into "Enable Proportional Editing"?

If the prefix "Enable" isn't part of the naming conventions like "Show" is, then that could still work but it seems a bit less clear to people reading it.

(By the way, interestingly the Viewport X-Ray button actually is missing the option to add it to quick favorites.)

It does a better job explaining now than before. We are, of course, limited to short text and cannot give a full wordy description, but this gets the idea across better. The previous phrase "like gizmos and outlines" is 50% wrong, because they are *not* gizmos, and that is extremely confusing because it is, in fact, the wrong word entirely. The other 50% "like outlines" gives only a single example, but we need at least 2–3 other examples to get the idea across descriptively. But that would be too long, and it is a bad UX to describe a feature by a subset of examples. My proposed "scene and object overlays" describes it completely (each and every overlay pertains to either the object—like outlines— or the scene—like grid lines). The only word that can describe all the types of things encompassed by that menu is, in fact, "overlays", so my approach is to narrow down the idea of overlays with the specific classifications they apply to. The user might have to click the button to get a better understanding because there isn't a highly specific English word that magically describes the entire concept, but it is way better to avoid outright confusion from an inconsistent, incomplete example that is currently in use.

The description can be:

Display overlays for selection and editing on top of the scene and objects

How about Display scene and object overlays for selection and editing? Because that implies they are overlays *about/related to* the scene and objects (as they are "scene and object overlays", and thus also overlaid over the scene and objects), which then encompasses the concept that overlays also include things like the grid and axes, but then it includes your suggested description about "selection and editing" to help the user understand also their purpose. This is also shorter:

Display overlays for selection and editing on top of the scene and objects
vs.
Display scene and object overlays for selection and editing

That is inconsistent with the overlays toggle which makes no attempt to indicate that it is a master toggle. But because of the compact design of these buttons, the user likely won't associate the tool tip for these tiny toggle buttons with the action caused from clicking the tiny button, they will instead associate the tooltip description with the function of the entire menu, so that is what it ought to describe in order to be useful and not confusing (how do the popover menu listings deal with gizmos "of all types"? and is that really the most useful way possible to describe their function?). A classification of "gizmos of all types" doesn't clear up what these "gizmo" things are as a comprehensive classification, but "interactive gizmos" goes much further towards hinting about what they are, and most importantly, how they intuitively differ from overlays, which are not interactive. That's a crucial distinction which will help users tell the two classifications apart.

The description can be:

When disabled, hide all types of interactive gizmos in the viewport

That definitely sounds better! I shortened it slightly from:
When disabled, hide all types of interactive gizmos in the viewport
to:
When disabled, hide all interactive viewport gizmos

• gizmos in the viewport is shorter as just viewport gizmos
• hide all types of is shorter as just hide all because they both describe the same result (in either case, it says all the gizmos are hidden)