[2.0.1] The 'prop_type_adapter' annotations is not always added to $prop['ui_patterns']

Testing env.

• Drupal 11.1.2, UIP2, theme ui_suite_bootstrap
• I copied a breadcrumb from radix and inserted it as a component into ui_suite_bootstrap. I saved the whole structure of the radix component (just renamed it breadcrumb_radix) to compare ui_suite_bootstrap and radix variations of the breadcrumb.
• Alongside with ui_suite_bootstrap component, I added the radix version in the breadcrumb.html.twig template for comparison.

Twig tweak module with debugging shows that radix version contains all necessary data and doesn't work properly with UIP2 mostly because of the naming of variables.
Radix version uses the default core twig template for the breadcrumb with"url" and "text" naming (see function template_preprocess_breadcrumb() in core theme.inc)
In BreadcrumbSource (UIP2) as I see we rename "text" into "title" and the related ui_suite_bootstrap theme uses "url" and "title" instead of "url" and "text" naming in the breadcrumb component in twig template.

It seems the Radix breadcrumb component receives already changed links props in $variables['breadcrumb'] from UIP2 in the twig template.
Unfortunately, I can't clue why xdebug is not triggering in the BreadcrumbSource on my local copy.
I can't figure out which step contains changing breadcrumb array because $variables['breadcrumb'] in the template_preprocess_breadcrumb() in Core contains pairs URL + text.

UPD.
I discussed this issue with @pdureau and he suggests look at these parts of the code:

Because the "normal" Links prop type was triggered before. We look for adapter plugins only if no source plugin was matched:

    if ($prop_type->getPluginId() === $fallback_prop_type_id) {
      $prop_type_adapter = $this->propTypeAdapterPluginManager->guessFromSchema($prop);

https://git.drupalcode.org/project/ui_patterns/-/blob/2.0.x/src/Componen...

So maybe (maybe because the real fix may be somewhere else) the Links prop type schema is too liberal, and catch some props which are not complaints (like this breadcrumb).

schema: [
    'type' => 'array',
    'items' => [
      'type' => 'object',
      'properties' => [
        'title' => ['type' => 'string'],
        'url' => ['$ref' => 'ui-patterns://url'],
        'attributes' => ['$ref' => 'ui-patterns://attributes'],
        'link_attributes' => ['$ref' => 'ui-patterns://attributes'],
        'below' => [
          'type' => 'array',
          'items' => [
            'type' => 'object',
          ],
        ],
      ],
    ],
  ],

https://git.drupalcode.org/project/ui_patterns/-/blob/2.0.x/src/Plugin/U...

Will setting a"title" as a required property be relevant? No side effects?

Sorry for postponing the task.
What I found during debugging:
LinksPropType is executed when Breadcrumb has already executed and prepared links in both variants.

During the execution of the normalizeLink() in the LinksPropType, the UIP2 unset $item["text"], which contains an object with the link's title.
After that, twig templates containing links implemented by Drupal Core twig template examples (e.g. links.html.twig, breadcrumb.html.twig) look broken.

In my point of view, we can do something like that:

    if (array_key_exists("text", $item)) {
      // Examples: links.html.twig, breadcrumb.html.twig, pager.html.twig,
      // views_mini_pager.html.twig.
      $item["title"] = $item["text"];
      unset($item["text"]);
    }
    $item["title"] = static::convertToString($item["title"]);
    $item["text"] = $item["title"];

If unset($item["text"]) is put inside a comment or use the code above, breadcrumbs work flawlessly for both variations.

In this case, we have a kind of fallback for Core-related twig templates but with a converted string for the link's title by UIP2 way.

hello there :) interesting issue and discussion. from my point of view, it would be nice to have some new tests (with the solution or without any solution if no solution is required) of this issue. Ideally, those tests would cover different "classic" situations.