Entity label (title) field shouldn't be a base field but a required option to choose a field for.

To get this issue out of its theoretical state and to put first concrete possible changes to be made on the table:

As we can see in the active issue queue regarding references and reference form field widgets (I saw them coming ;-) this is an issue on a huge scale and that is the reason why my OT was so long. :-) In case we go that route proposed here to make any field created on that entity bundle type available to choose as the label we need also to consider another way we internally check for the choosen label field. Because we can not know OOTB which one it is. The choosen label field need to have an own "type register" where to look at for fields choosen as label on that bundle, which brings in a complete new way for reference form fields to fetch or display or select on lists etc.

This issue remains hard to understand, many words but few technical details.

The label is defined in 2 places AFAIK:
(1) the label() method on an entity, which is overriddable by swapping out the entity class or bundle class.
(2) The label key on the entity type annotation which is shared between all bundles of an entity type. It provides the default user by the label() method, as well as being used in queries like autocomplete queries.

So if there is a feature request here, it sounds like either:
(1) make entity keys (or at least the label key) overriddable at the bundle level
(2) provide a UI for configuring the label on a bundle

Probably (2) depends on (1) anyway.

(1) profoundly changes assumptions about the data structure of Drupal entities. To ensure BC we would have to replace the getEntityKey() method with a getBundleKey() or at least add the latter. And this leads to complications - possibly insurmountable - when querying across multiple bundles.

Fundamentally I think this issue is wrongly targeted. Its focus should be on making it easier for entity autocomplete in particular to query across fields other than the entity label. The problem is not the entity label data structure, it's with autocomplete's narrow focus on the label.

Is this about entity reference field autocomplete?

If so, what's wrong with the established technique of using a view to provide the entity suggestions. That does allow you to specify the entity fields to search on.

You're right. So my retitling was a mistake.

We can already specify any field we like to be the label, so the IS is misleading.

The feature request here has to be: Allow entity keys to be definable/overriddable per bundle per #25.

But this is a big change in the architectural model for a small gain, so I have to think we should close as won't fix.

Thanks for joining. There are many possibilities for misunderstanding. Also on my side for sure. But please do not change the title immediately from your POV without discussion what this is about here. The OT summary is too long as already discussed earlier and I was about to change that while this issue now feels slidely hijacked and from the original purpose more and more drifting. All your good ideas regarding "what it possibly means technically to change for that" are possibly right and maybe part of follow ups (tasks). But this issue needs some work on the OT from the original poster before we can discuss its tasks or possible confusions in it. Sorry that I missed no comment that I am already working on the OT summary

Best points until now have been made in #13 and #14 so far.

The other way is to not rely on one special field created only for that purpose, but relying on a flag on a field stating that this field is the label now, as explained multiple times above in other words.

This is already the case. The 'label' key in the entity keys section of the entity annotation defines which basefield is the label. There is no requirement to create a basefield specifically for the purpose of being the label.

For example, the title field is the label field for the node entity, the id field could perfectly well be the label.

/**
 * Defines the node entity class.
 *
 * @ContentEntityType(
 *   id = "node",
...
 *   entity_keys = {
 *     "id" = "nid",
 *     "revision" = "vid",
 *     "bundle" = "type",
 *     "label" = "title",
...
 *   },
...
 * )
 */
class Node extends EditorialContentEntityBase implements NodeInterface {

I am not clear from the comments in this issue what about this is insufficient.

The way the current approach is architected means the selected field must be a basefield, it cannot be a diffrent field on each bundle, such as a configurable field. If this is the concern, then the feature request here seems to boil down to: Allow entity keys to be definable/overriddable per bundle.

We can already specify any field we like to be the label, so the IS is misleading.

The OT ist not "misleading". The starting date of the issue is some years ahead. Maybe I missed something lately which makes the whole issue already obsolete.

@ #29: Thanks for trying to clarify your thoughts. As stated above (before): I will investigate in the next spare time on possible misunderstandings and on sharpening the idea discussed here. Plus: There is a big chance that I am not aware of that this issue already run far out of date.

Many things have changed over the years already. And the standard install profile of Drupal core - which was somewhat unspokenly the basis of this issue attempt - will maybe become less important in the near future. Especially with the starshot initiative getting momentum. So, many of the thoughts in here can be considered outdated. Or rather "absorbed". In a positive way.

To clarify: Most of the misunderstandings in here in between were mainly caused by the fact that the IS tries to cover the "no-code" impressions from average users UI perspective on a standard install profile. While some participations on the disucssion are referring to ways to change that in code or non standard profile scenarios, f.e. custom entities and such.

Misleading or not, maybe too non-technical in some aspects, also, yes, and last but not least too theoretical and mostly based on the assumption, that users are rather familiar with creating node types and fields on node types like provided in the standard profile, the idea behind all this has been somewhat absorbed already in different evolutions of the whole Drupal concept and eco system over the years. Users get more and more used to custom entities and the understanding of fields, base fields and labels are evolved.

So, after thinking about it for a while now if it makes sense to invest more time in here to clarfiy or narrow the idea into a more understandable concept, while parts of it are already "fixed" in other ways, I came to the conclusion to close this issue as outdated.

In case some of it could need further discussion it would rather make more sense to create a new issue to prevent wasted efforts of users reading all of the previously obsolete content.