This is a bug and a regression from tdf#159549. File it.
But it seems to me, that you wasn’t completely correct when writing your question - just because, I guess, if you would search exactly for Endnote anchor
, it wouldn’t fail. My assumption - based on my own experiment - is that you used the procedure like this: in the AltSearch dialog, you clicked the “Replace” drop-down, selected “Character style” element, and then in the “Select style” dialog, chose “Endnote Anchor” element there (with both words capitalized!). That created the replacement string \C{Endnote Anchor}
, again with both initial characters capitalized, and that gave the error, which you typed yourself in the question (and overlooked the different character case), instead of copying and pasting? Note that details matter. And note that you can workaround it for now - replacing the capitalization.
The regression can be demonstrated by this Basic code:
family = ThisComponent.StyleFamilies.getByName("CharacterStyles")
for each n in family.getElementNames()
style = family.getByName(n)
if (not family.hasByName(style.DisplayName)) then MsgBox style.DisplayName
next n
Previously, hasByName / getByName accepted not only programmatic names, but also display names. This is exploited by AltSearch (its GetStyles produces an array of display names, and these strings are used further). Of course, the extension could be improved by keeping the programmatic name along with display name, and using the programmatic name where needed - but it’s impossible to make sure that countless macros and other extensions do not rely on that. And there is no explicit restriction in StyleFamily service, which names are accepted or not - so this change is an API break.
EDIT:
Hmm, likely it doesn’t make sense to file a bug. This change is documented as an API change in the release notes. So the only way forward is to ask the extension maintainer to fix it.