The paths that the fieldlayout field is looking in are the generic paths for the renderer for ALL fields. It is not looking at the override path for the specific plugin.

The generic renderer is analogous to the module chrome not the module layout

I copy my comments here from #46313 .
In short: it is not a bug, but misunderstanding due poor documentation.

There is 2 layout systems working here, and they are not interchangeable.

1. Layouts from tmpl/ which renders the field value. It can be only one, so no reason to create dropdown for it.
   

   joomla-cms/administrator/components/com_fields/src/Plugin/FieldsPlugin.php

   Lines 222 to 228 in 1c654ef

   	// Get the path for the layout file
   	$path = PluginHelper::getLayoutPath('fields', $this->_name, $field->type);
   	// Render the layout
   	ob_start();
   	include $path;
   	$output = ob_get_clean();

2. Layouts from layouts/ which renders the wraper around the value, and label. This you can select in the field parameters.

Create file templates/cassiopeia/html/layouts/com_fields/field/foobar.php. And it will be available in that layout dropdown.

and i repeat that this might be what the code does but it is wrong. as I said before this is the render for all fields and not the output of the specific field. The render is the same as a module chrome it is not a layout

The render is the same as a module chrome it is not a layout

Yes. it renders "wrappers" for the field value and label.

You want multiple tmpl/ and be able to select it like for module tmpl/?
Then it will be new feature.

I just want to be able to use the template override as created by the template manager.

It already works.
You create an override and it will be used automatically, no need to select anything.

If it works automatically. Then the field of the layout list in the parameters of the field that should display the override list is not correctly named. Either the list of layouts should be named differently, or since the list of layouts redefines something completely different than necessary, or the name of the field in the list of layouts should be renamed to a more precise definition.
For the sake of example: the content of an article can be called text and the content of a category can be called text. Imagine that in the admin panel there are 2 positions with the same TEXT names. Opening one takes you to the article, opening the other takes you to the categories, but they both have the same name in the menu. This does not reflect the difference between categories and articles.
It's the same here, we need to add a clarification to the current field so that it's clear that this is not a layout of a custom field, but a layout of a system field, or add a new function so that we get a redefinition of the user field.

Well, in general, using an automatic function to redefine the layouts of the system field is stupid. Since we are redefining the layout of the plugin and not the system input field.
It may be very good that you can redefine the system input field, but the list of layouts in the plugin should specifically choose to redefine the layout of the entire plugin and not the system field.

Fedik probably doesn't want to fully express his thought for some reason.

There is an interesting point.
If you create a redefinition of the field layout in the TMPL folder of the field plugin. Then a new field will appear in the admin panel.
If we create a file resize.php For the MEDIA field in the /fields/media/tmpl folder, a new field named MEDIA_RESIZE will appear in the list of content fields.
There are 2 problems:

1. The site administrator will not know that a new field has appeared, as it is strange to expect such a thing.
2. It makes no sense to have a new field in the list of content fields, since the configuration of the new field is exactly the same as that of the original field.
3. After selecting a field and saving the parameters, it is not possible to switch the field to another with the same type.
4. But at the same time, there are no specific parameters in the new field element at all. How to create a new field is a text field

The new field item makes sense when we redefine the XML file, since the values and configuration will be different. by analogy, the type of menu item.

The plugin field has a PARAMS folder, just if we were creating an XML file override in it, we would expect a new field in the administrator's list. And to redefine the layout in the TMPL folder, we expect a new layout for selecting the layout of the original field.

There is one more feature. If in parallel with the created layout redefinition XXX.php create a XXX override.xml and put new parameters in it. Then indeed All the new parameters will be displayed in the settings of the new field with the same type.
But a new field with the same type appears only if there is a layout file. This means that when you redefine a layout template in a component, you need to redefine the XML file in the PARAMS folder at the same time, or you can't add a new field with the same type to the field list. Or you need to create new documentation to tell us that this is a special new feature in the CMS.