When we last redid the route machine names, the decision was made that they had to be modulename.something_descriptive, and that there could only be one dot in the name.
I disagreed with that restriction, so I'd be more than fine updating the route machine names to match the menu link defaults.

But, not all routes have a corresponding menu link, so we'd have some grey area in renaming *all* of the routes.

One thing to consider if we do touch all the routes: Those files are roughly in order of when the route were converted, and make absolutely no sense. We should consider reordering them at the same time.

I really think that this kind of renaming tasks should be moved until we really have a big picture what we really want, which is probably after fixing the conversions. You know, my opinion is is basically: make it in a way, that it is not overcomplex due to our addition of rules, but also don't assume that developers are stupid.

Woah, and I thought this may be an easy issue to look at :D It is hard to decipher how/why the menu machine names are easier to understand vs. the route names? Some examples would be great for A/B comparisons.

I am also missing a cluebat I guess on why the menu link names are preferable. They are hard-coding the default path into the machine name, a path which by design is intended to be de-coupled from the route. Additionally, there are going to be more route names than menu link names, so using the menu link name again doesn't make sense to me.

We spent time making all of the route names consistent, why can we not just use them in two places?

I support the previous decision to use the module_name.some_description format as discussed in #1981368: Convert all routes to 'module_name.foo_bar' naming convention. Without having in-depth knowledge of views_ui module (as an example) I had no problem understanding the meaning of the route or recognising a corresponding page or form from only reading the current (single dot) route names.

For consistency I would vote for option 1, to change the menu link machine names to match the route names. A single pattern to learn and therefore better DX.

I made a dump of all static route names (taken from *.routing.yml files). I found 330 routes, and in #7 I found 80 menu links. Renaming routes would not be my priority, be if we do I have a few suggestion:

Do not use "admin_" prefix. It is probably a result of the (former) path_as_route_name strategy.

Yeah, we could always discuss re-introducing "sub-namespaces" later, and come up with some guidelines on when we do/do not do that.

Is now an appropriate time to do that, and is this an appropriate issue in which to do it? If so, I'd recommend for entity types and plugin types (i.e., well defined nouns in Drupal's domain language), to use "." as separator. For example, an "image style" is an entity type and an "image effect" is a plugin type, so because of that, those are nouns with well defined meaning in image.module. So instead of image.style_delete and image.effect_delete, I recommend image.style.delete and image.effect.delete.

Re #10, +1 on dropping "admin_", "_page", and "_form". However:

Avoid "_list", use "_overview" instead.

Why? "List" is the term we already use in the entity system, so why use a different term in the route name? I'd suggest the opposite: that for any route that is an entity list but that currently uses "overview" in its name, that we change it to "list". So per #4, we change node.overview_types to node.type.list, since it's a list of node types. I think we have some overview pages that aren't entity lists, so those can possibly remain "overview".

Note that #11 might be moot if/when we do #2150747: Switch back to URI templates in entity annotations, since that might pull all entity operation routes out of *.routing.yml. But the fate of that issue is still uncertain, so not sure if we want to proceed here without renaming routes, or with trying to rename them to something we like, so that if that issue doesn't happen, we still have route and link names that we like.

To me, this issue should simply do what it says: make the link and route names the match. This is a critical, beta blocking DX problem with the current router/menu link system separation. And since there are far more route names than there are menu links, we should use the route names. Done.

Then, if we want to further bikeshed what we should name these machine names, we can do that in a non-critical, non-beta blocking "nice to have" issue.

re: #13. It's impossible to use the route name for all cases - e.g. a sub-tab.

So, is it better DX to have the machine name USUALLY match the route but sometimes be different?

I understand that looking these up can be a pain if they are distinct, but I'm a bit worried and frustrated that we are going to be back to the hook_menu scenario where most devs had NFI what was actually going on becuase many things used the same name/data.

It's impossible to use the route name for all cases - e.g. a sub-tab. So, is it better DX to have the machine name USUALLY match the route but sometimes be different?

Is that question relevant to this issue? From what I can tell, it's ok for a menu link machine name to be the same as a local task id. To test that, here's a patch that changes system.admin.appearance to system.themes_page even though system.themes_page also exists in system.local_tasks.yml. Doing so doesn't appear to create any conflict from what I can tell in local testing.

So I think what you're pointing out is just an issue for *.local_tasks.yml, where we have both system.theme_settings and system.theme_settings_global as local task ids that both use the system.theme_settings route. Pre-existing condition in HEAD, but yes, I do think that is better DX than to rename all local task ids to never match their route names.

The point I'm making is that it basically gets us back to D7 in terms of possible dev confusion, and I'm worried we've wasted a lot of time to go in a circle.

In D7, I think the confusion was mostly due to the key of the array returned by hook_menu() being simultaneously a route identifier, a menu link identifier, and a local task identifier. Not that the same string value was used for all 3, but that all 3 concepts were literally wrapped up in the same hook, and our other menu.inc functions didn't separate out the concepts in a very clear way.

Now that the 3 concepts are very nicely separated, I don't see where the confusion would come from in having the same identifiers. For example, just like I don't think there's any confusion in book.settings being both the name of a config object/file and the name of a route, I also don't think there's any confusion in it also being the name of a local task and/or a menu link.

Is there any specific code snippet or debugging example you can come up with to demonstrate where it's not clear what kind of object you're identifying?

While looking for good or bad DX effects of making route and menu link names match, I discovered this positive effect. Take the #19 example and this scenario: When reading the code below, I ask myself what is the route of this "parent system.admin.reports"?

Currently it requires two search actions to answer the question. 1. search for "system.admin.reports" and find the menu link that uses this as a key (11 results in 6 files). 2. Take the route name of this link ("system.admin_reports") and search for its definition (5 results in 3 files). The result is found in a *.routing.yml file since route definitions are in files like that. When route and menu link names match the parent route definition is found just by a single search and the route is found in a *.routing.yml file.

Perhaps we can find some convention of a prefix or suffix that at least avoids them all being the same string?

I'm not necessarily opposed to prefixing all menu link machine names with menu_link., but that would be different than what we do in every other part of Drupal, where IDs are only unique within their namespace. So I think it only makes sense if we're confident that the potential for developer confusion in seeing a bare ID without clarity on whether it's a link or a route is greater than the potential for confusion in applying a custom ID pattern in this one place. So, any feedback on #24?

Of note, based on a discussion with pwolanin, I removed the hook_menu_link_defaults section in custom_block.module as these are local tasks. Also, in menu_test.module I left these as is, but updated $items to be $links for consistencies sake.

Interestingly - if the specified parent machine name doesn't exist, you get unpleasant SQL errors. Maybe we should throw an exception, rather than try to save this invalid data. See linee ~ 1686 in menu.inc below "Handle any children we didn't find starting from top-level links.".