From a usability perspective, changing the index via the spinner is not so intuitive. Then I feel it would be helpful to have a function to move the selected point to either the most top or most bottom (this should allow creating a preferred triangle by applying it any three points in cases where symmetrical quadrilateral occur like #66336).

It's possible to type into the index field a number higher than the number of points to clamp it to the top, or a negative number to clamp it to 0. Is this not satisfactory?

@vaner-org That might be sufficient to some extent. However, since there's no way for users to know this within the editor, it should probably be documented somewhere, like in a tooltip or at least in the documentation. Ideally, right-clicking might bring up options including renaming, but if that's too much work, just the documentation for now should suffice (and I think we can send the right-click option as follow up PR later).

(from rocketchat) I'm not happy about changing from returning a cached StringName name; to calling String get_blend_point_name(int p_point) const; which then must perform itos(i) followed by String -> StringName conversion, at every _process

If the names could be cached, I might feel better about it. Or maybe, for compatibility, we should always store the number as the name, and if the name is numeric, then it always uses an index and ignores the name.

@lyuma That case parameters/blendspace2d/ + get_blend_point_name(0) exists solely for compatibility with niche scenarios where paths depend on dynamically changing points. If you want to cache the path name in cases where it depends on this dynamic path, you would likely need to handle caching on the user side before and after add_point() or remove_point(). Alternatively, adding a signal like points_reordered could be another approach to consider.

However, as I mentioned above, I believe use cases that rely on paths being dynamically changed are niche. So in most normal cases where you're just accessing path parameters/blendspace2d/0 (0 is "name", not "index") shouldn't affect performance. The current BlendSpace dynamically transcribes index into name using itos, so my suggestion in #110369 (comment) for this PR simply always prevents name from being changed automatically. Furthermore, I argue that inconsistent path behavior depend on whether it is number or not should be avoided, as it can cause confusion.

Pending further opinions, I do request that this PR not close #66336, because if the important part that indexes play in animation blending isn't exposed and made apparent to the user, a lot of unpredictable things can occur. I know it caused me a great deal of confusion before I understood it.

While blendpoint indexes remain a necessary evil that hold serious influence over animation blending, I don't think they should be swept under the rug.

Failing checks against the extension API. The name must be added as a non-optional member, so has to be before index in add_blend_point(). How should I proceed?

I think there are two approaches.

1. Make the string optional, disallowing empty name only when it's #ifdef DISABLE_DEPRECATED, and fallback to automatic naming with a warning like In the future, empty names will be deprecated, so explicitly passing a name is recommended. in #else block, also empty name is prevented by editor (means that warning is only shown by user script)
2. Move the string before the index and rename it as new function like add_blend_point_with_name() with comment TODO: In Godot5, it should become add_blend_point(), and mark the old API as deprecated in xml like <method name="add_blend_point" deprecated="Will be replaced with add_blend_point_with_name in the future.">, and make editor to use add_blend_point_with_name only. Then no longer needed to add .compat.inc

Regarding approach no. 2, isn't it problematic to say that add_blend_point will be replaced with add_blend_point_with_name in the future, when actually the latter will be taking the add_blend_point name when replacement does happen?

For approach no. 1, the current .compat.inc and refactors remain, correct? With just an additional #ifdef DISABLE_DEPRECATED block inside add_blend_point? If so, I'm leaning towards preferring it, since the inferred name can also be conveyed to the user with the warning they are given.

No 2 depends on a future ProjectConverter (as was done from Godot 3 to 4). I think 1 is acceptable for now.

Looks like I'm going to have to add exclusions anyway to pass CI. Is it still worth it to do all of our circumventions to add_blend_point?

If a compatibility method definitely exists, simply add the text file of the expected error to the CI exclusion as godot\misc\extension_api_validation\4.6-stable\GH-110369.txt.

I think now this PR code is fine, I will test and re-review in Animation meeting this weekend. Can you squash commits into one?

We discussed this at the animation meeting, but it was difficult to find consensus.

To clarify, the main concern was likely compatibility issues.

In older projects, for example, when a parameter like BlendSpace2D/3/blend_position existed, after deleting a point, its path would be automatically changed to BlendSpace2D/2/blend_position. However, there should be agreement that this "automatic path change behavior is inconvenient."

While scripts based on this automatic path change behavior (though I believe this is a niche case) will break compatibility, I believe the migration path is secure as demonstrated above using get_blend_point_name(). Except for that niche case, no migration is required as long as disable_deprecated is false.

Even without this, it might not prevent you from making games, but since it's inconvenient that we can't assign arbitrary names to nested BlendTrees like BlendSpace2D/NestedBlendSpace2D/blend_position, I suggest to merge this PR.