Data attributes of a new link are always applied to the FIRST link

Thanks so much for reporting this and for the proposed fix. Assigning myself for review...

The first pass at the fix relies on trying to first read the selection's link Href attribute, and if it can't find that, using the raw href value. This won't work if there are two or more links with the same raw href value, as demonstrated in this video below. Screencast and steps to reproduce the problem:

https://www.youtube.com/watch?v=K7HvqUJAd0U

1. Create a node titled "First node"
2. Create a node titled "Second node"
3. Create a node with some body content. Create two links in the body content, both linking to "Second node."
4. Using "collapsed" selection (i.e., click inside the link), click the second link and update the display text and save.
5. Observe that the link is now split into two, since the link range is being defined by the first link, not the second link.

Okay, since Linkit has the additional capability of updating the Link Href value, in order to find the correct link target when the selection is collapsed, we need to know the new href, not the "old" href. Testing shows that this behaves reliably with multiple links present, and when multiple links share the same href, because the range is being derived from the selection's first position -- i.e., where the cursor is located.

MR updated. This works for me, but a second confirmation would be greatly appreciated!

export function getCurrentLinkRange(model, selection, hrefSourceValue) {
  const position = selection.getFirstPosition();
  const linkRange = findAttributeRange(position, 'linkHref', hrefSourceValue, model);
  return linkRange;
};

MR doesn't apply to 7.0.10 - is that because it's off latest unreleased dev?

Yep! That's the typical merge request workflow: it's set to merge into the latest commit in the project's development branch, rather than representing a relationship to the latest tag for a project.

Fantastic sleuthing. I'll prioritize reviewing the proposed changes to both projects today. Thanks for the significant effort given to this problem!

Just a minor adjustment to ensure this doesn't break BC compatibility on sites still using CKEditor5 < v45 (Drupal < 10.5 / Drupal < 11.2).

This is not a concern for Editor Advanced Link, since its 2.3.x branch already sets Drupal core constraints to enforce CKEditor >= v45.

Summary of what I tested, using Linkit and Editor Advanced Link in conjunction:

(All scenarios below assume activating change to a link by clicking "inside" the link, what CKEditor calls a "collapsed" selection):

1. When two or more links are present, editing the displayed test of the second link correctly updates the text of the second link (where previously it was updating the first), and the link is not "split" into multiple mangled links.
2. When two or more links are present, editing the href of the second link correctly updates the href of the second link (where previously it was updating the first), and the link is not "split" into multiple mangled links.
3. When any of the "Link properties" interface are toggled (i.e., the "Open in new window" from Editor Advanced Link) and the link "Update" button is subsequently pressed, the cursor moves to the end of the link, and the link is not "split" into multiple mangled links.

Thanks again, @jannakha, for reporting this and contributing significant effort to pin down this squirrelly issue. I, for one, have a much better grasp of CKEditor5's API after this!