I personally use this report a lot especially to understand the architecture of websites I did not build myself, or just to remember how I handle data in websites built years earlier.
Personally I think the only way to avoid such a report would be to get rid of sharing fields acros entity bundles entirely (which would in turn simplify field UI and maybe the internal Entity field API). Just my 2 cents
The strongest possible -1 from an accessibility standpoint. This feature would encourage a bad practice that unfortunately is very popular on the Internet.
I think we are not considering shared (cheap) hosting environments. Nowadays you already have to pay higher hosting costs due to the fact that SSH access is required if you do not want Drupal's maintenance to become a pure nightmare; the automatic-upgrades initiative should mitigate this IMHO (see wordpress automagical updates as the reference target). The whole idea of separate environments works great for enterprise use-cases, but for simpler websites is not very sustainable.
So, are we officially saying we do not care about hamateur websites? I have nothing in contrast with that vision, but then we should optimize Drupal for that use case.
@cilefen fair enough; we should discuss wether that workaround is acceptable for being in 2024 (and of course I'd say no), but I do not want to bikeshed on this: we'd better have this discussion in a policy issue.
Anyways I did not find anything on the fac that taxonomy term pages are now views; do you have the CR on hand? A quick Google search didn't help
@cilefen I'm not sure I agree on considering this a feature request than a bug. Reading the help text "Start typing the title of a piece of content to select it. You can also enter an internal path "that is shown below the field it seems that its intended behavior would be to autocomplete paths for all "pieces of content" (and in deed taxonomy terms are content entities).
Anyway this is at least a major usability issue, considering the fact that we do not have any simple way in core to add taxonomy terms to menus (like the options available for nodes).
On a side note, the reason why after 10 or so years of work on entity field API and internal core architectures we still have to worry about implementations for each content entity is still a mistery for me, but that's another story :)
falcon03 → created an issue.