Thanks!

This PR conflict with

What do you mean by "it conflicts" with the code?

What do you mean by "it conflicts" with the code?

I mean:
When a child node was added to parent_node with add_child, parent node will check it's name with _validate_child_name,
and invalid char or duplicated name with replace with @ char , then it will trigger this warning, sometimes alot, and it's not trackable through these messages, especially in editor code. _validate_child_name function need to modify too.

How is this warning triggered? set_name isn't called anywhere in add_child as far as I can see?

How is this warning triggered? set_name isn't called anywhere in add_child as far as I can see?

There is no detail infomation in these warnings, so it's hard to tell where is it come from.
And it's hard to reproduce, I got some label name warning maybe cause by some addon creating list of labels with same default name, But after I changed @ to _ in _validate_child_name in my local build, no more warnings.

BTW, since we restrict on invalid node name characters, I think they should not use internal too.

I'd suggest opening a bug report, but just adding a child doesn't cause the name to be set so this can't be all that's done in this case, I'd say that it might be that you're reassigning the name or something

Node.duplicate() calls set_name, and can be used on nodes instantiated from code with a default generated @ name, so this would trigger warnings.

There might be other uses of set_name outside of Node in subclasses. So I think this warning might indeed be raised frequently outside of the users' control.

Random example:

resources/3d/importer_mesh.cpp
588:            mesh->set_name(get_name());

3d/mesh_instance_3d.cpp
259:    static_body->set_name(String(get_name()) + "_col");
289:    static_body->set_name(String(get_name()) + "_col");
328:    static_body->set_name(String(get_name()) + "_col");

I haven't tested any build with this PR, but the above concern is valid in my opinion.
I think the review process of this PR was a bit too hasty. The lack of a warning prior to this PR makes me think some Godot developers, and even Godot's codebase, may be using this behavior on purpose without calling String.validate_node_name() beforehand. That, plus the engine already validates Node names every time they are set, so calling that method manually is wasteful.

I think that should've been considered before merging this PR and I would personally revert this.