Hm, so the suggestion would be that, if a scroll-to-element operation is performed, we properly indicate that element as the active one, but if you scroll in any way that's not directly to an element (manually, or via scrollTo or scrollBy), we re-select the active element by "closest to aligned" as normal?

That actually sounds pretty reasonable to me. Playing with your example, it's somewhat confusing/weird that clicking on the last several items doesn't do anything, even change the scroll marker. I think it would be a better UI to have the clicked marker styled as active, even if it doesn't actually move the scroller at all.

Yup, and further, we could use the scrolled-to-element, when set, as the anchor node which would make navigating to a page with a fragment always keep the targeted fragment visible rather than potentially anchoring to some other element as page content loads in.

So the proposal is:
We track the last scroll targeted element within each scrolling container, initially null.

When any scroll of a scroll container occurs:

1. If the scroll targets a particular element, (e.g. scrollIntoView, fragment navigation), then that element is used as the last scroll targeted element.
2. Otherwise, if the element snaps to a particular element, that element is selected as the last scroll targeted element.
3. Otherwise, it is set to null.

This last scroll targeted element is used as the anchor node for scroll anchoring, and as the start point to search for the current scroll target for scroll markers.

Some details:

1. If the target is in a nested scroller, should we track the nested scroller instead? I think it's strictly more powerful if we track the targeted element but could see an argument for this.
2. If the target node is removed, presumably we want to forget about it at that point, but this does mean a moved node would be lost.

For Table of Contents cases, I can generally remember 3 different types of designs that are related to this issue:

1. The “only the last visible scroll-target is highlighted” (the common use case)
2. The “all visible before and including the last visible scroll-target are highlighted” (the one in this issue + cases when there are many small sections in ToC and we want to mark all of them)
3. All previous scroll-targets are highlighted (when all “already read” sections of a ToC are dimmed, for example).

I wonder if we'd want to have a control over which we choose, and maybe more than one pseudo-class for this? So not just :target-current, but two more (needs bikeshedding, but basically :target-current-visible for 2 and :target-previous for 3 (and, I guess, we could want :target-next? alongside))

We could have some logic similar to the one in the latest comment, but I wonder if having more explicit way to control it could be better? (alternative to multiple pseudoclasses could be a separate property that says how the :target-current should be selected, I guess?)

@kizu this issue is focused specifically on enabling :target-current to have a target that best represents the common case of only one target is highlighted. I'm happy to pursue adding other pseudo-classes but I don't think it changes that we should resolve on behavior for this pseudo-class to be able to select a particular element where mutliple share the same scroll aligned position.

The CSS Working Group just discussed [css-overflow-5] Allowing markers to be active even when not scrollable to aligned position, and agreed to the following:

• RESOLVED: Adopt proposal in https://github.com/w3c/csswg-drafts/issues/10738#issuecomment-2448204794 to anchor to identified elements

FWIW, I like the idea of targeting elements for scroll anchoring; I suggested it a very long time ago but never got to implementing it.