*Edit*, comment removed.

Some of these described reasons I agree with, but many of these reasons stated above are simply defenses of status quo.

"Visual Noise" can be used as a cudgel against making anything longer, more detailed, or more descriptive. It gives examples of taking it to "logical extreme" but at the other extreme it should be an argument for making menu items SHORTER. Because if longer items are bad then shorter must be better. But that isn't the case and we aren't recommending shortening menu items. This is just arguing for keeping things exactly as they are.

"Unpredictable Menu Search" is describing only shortcomings in search as that feature could, or could not, include dynamic text.

"Complicates Documentation" is a straw man argument as the example is not that complex. The example item is now "Rename Active Item". Therefore the "bad" documentation example would be "Edit -> Rename "Name of Active Item"

"Complicates Translations" is merely a note that we'd have to do so with translations in mind. And it specifically mentions a shortcoming in a specific version of a patch of mine that would be fixed in review, not accepted as-is.

"Complicates Menu Memory" is only saying that a function would need to support this. That is not a argument against, but only an argument that any change is work. But all changes are work, good or bad.

In my mind the reasons for DOING dynamic text is for when the action or target of the action is not clear. Having an menu item that just says "UNDO" or "REDO" tells you nothing of what is being done and is helped by adding specific information.

And "Rename" is helped by the name of the object just because it is not always clear what the active item is. Quite often it is hard to differentiate an active item from among a group of selected items. And there are times when the active item is not even shown, even when there are selected items (looking at you box select).

Similarly "repeat last" may as well be "repeat random action" as it is often unclear what will be repeated. And "Adjust Last Operation" might not be the last operation as far as the user is concerned.

Mostly agree with Harley Acheson points, I'm sure there are places where having names of items is useless at best or harmful at worse. In search menus or results I'd mostly agree they should be absent.

In T76213#934190, @Harley Acheson (harley) wrote:

Having an menu item that just says "UNDO" or "REDO" tells you nothing of what is being done
Similarly "repeat last" may as well be "repeat random action" as it is often unclear what will be repeated. And "Adjust Last Operation" might not be the last operation as far as the user is concerned.

In undo/redo they make sense to know which operation you are undoing exactly. It is not always clear what actions push an undo which don't, or at which stage of stack you stand after a few "blind pushes" of Ctrl+Z.
Repeat last also benefits from knowing exactly what will be done, not all actions push a history entry, and it is not always clear what will be repeated

In T76213#934190, @Harley Acheson (harley) wrote:

And "Rename" is helped by the name of the object just because it is not always clear what the active item is.

This will be particularly true if/when we finally have multi-object properties editing. Could be made particularly useful to know if an operator will affect all selected items or just the active one.
Say Move X Selected items, or Rename 'Cube' vs Batch Rename X Selected items or Parent to Suzanne.

Names however should be presented in the UI in a distinctive manner that differentiates from the actual operator, maybe dimmed or in a different color like we currently do for menu paths, python tooltips or other "accessory" information.

@Harley Acheson (harley),

In T76213#934190, @Harley Acheson (harley) wrote:

Some of these described reasons I agree with, but many of these reasons stated above are simply defenses of status quo.

I can see where you're coming from, nevertheless, changing the status-quo can introduce new problems.
If those problems aren't accounted for, then we're adding new bugs/technical-debt.

"Visual Noise" can be used as a cudgel against making anything longer, more detailed, or more descriptive. It gives examples of taking it to "logical extreme" but at the other extreme it should be an argument for making menu items SHORTER. Because if longer items are bad then shorter must be better. But that isn't the case and we aren't recommending shortening menu items. This is just arguing for keeping things exactly as they are.

I wouldn't use this as an argument to make things shorter (it's a separate issue - if we have too much information to present - how to manage that).

The noise part comes from the tenancy for people to pay attention to things that change.

If you access a menu regularly you become familier with the order of items and the text, then one day it looks different, it draws attention to the change (maybe a short menu item is suddenly the longest menu item in the list).

If that change isn't important, your attention is captured for no good reason, making the UI more noisy.

"Unpredictable Menu Search" is describing only shortcomings in search as that feature could, or could not, include dynamic text.

Right, we can disable dynamic text for search, there is still a small disadvantage to having different text for search and the menu.

"Complicates Documentation" is a straw man argument as the example is not that complex. The example item is now "Rename Active Item". Therefore the "bad" documentation example would be "Edit -> Rename "Name of Active Item"

I'd argue any time you need to express that some part of UI text is dynamic - there is some overhead for people reading/writing docs.

Although in some cases it's not so bad, it's still a down-side.

"Complicates Translations" is merely a note that we'd have to do so with translations in mind. And it specifically mentions a shortcoming in a specific version of a patch of mine that would be fixed in review, not accepted as-is.

This is yet another thing we need to be aware of when reviewing code, something we could easily miss by accident and end up in a release.

"Complicates Menu Memory" is only saying that a function would need to support this. That is not a argument against, but only an argument that any change is work. But all changes are work, good or bad.

The reason I included this is this is not simply some feature to support with an obvious solution (a bug to be fixed for e.g).

Looking into the code and how it works, we would need to dedicate time to solving this problem - perhaps having a separate identifier for menu items which isn't dynamic, or detecting unique menu items using something besides their text...

The resulting code will be more complicated then the current code, and isn't obvious exactly how it should be solved.

In my mind the reasons for DOING dynamic text is for when the action or target of the action is not clear. Having an menu item that just says "UNDO" or "REDO" tells you nothing of what is being done and is helped by adding specific information.

Right, undo/redo can be exceptions.

And "Rename" is helped by the name of the object just because it is not always clear what the active item is. Quite often it is hard to differentiate an active item from among a group of selected items. And there are times when the active item is not even shown, even when there are selected items (looking at you box select).

I don't think rename is all that helpful, the active object / bone etc should always be obvious.

Many actions use the active object, and don't mention it by name.

Similarly "repeat last" may as well be "repeat random action" as it is often unclear what will be repeated. And "Adjust Last Operation" might not be the last operation as far as the user is concerned.

This is similar to Undo, an exception could be made for that.

Note that all of this isn't to say "never have dynamic text", just that we should have a high-bar for it's inclusion, given the issues it introduces.