In some situations, a Blueprint can become devoid of an Event Graph. While no graphs are present, multiple variables can be created with the same name.

In some situations, a Blueprint can become devoid of an Event Graph, or be created without one from the start. For example, function "FKismetEditorUtilities::CreateBlueprint()" in UE 5.4 does not call "FKismetEditorUtilities::CreateDefaultEventGraphs()" if the blueprint is derived from a C++ class marked as "Const". If the blueprint is later reparented, it can reach a state where an Event Graph is expected but non-existent.

It is not well known what other situations might also result in an EventGraph-less Blueprint, especially considering that the rules in earlier engine versions could have been different. At least one licensee has reported having blueprints derived from PrimaryDataAsset and without an Event Graph in UE 5.4 (such blueprints are expected to always have an Event Graph, even if an empty one).

When a Blueprint supports having variables but does not have any kind of graph (UberGraph, Functions, Macros...), the Editor allows variables to be created and renamed without checking for duplicate names. This results in potentially several variables existing with the same name, a situation that does not raise an error even when the blueprint is compiled. This behavior can be tracked down to function "SBlueprintPaletteItem::OnNameTextVerifyChanged()" in file [Engine\Source\Editor\Kismet\Private\SBlueprintPalette.cpp]. When "BlueprintObj->GetAllGraphs()" returns empty, there is no object to call "GetSchema()->GetNameValidator()" on, so the name check is skipped entirely.

Note that manually creating an Event Graph (or any other graph) on the blueprint is enough to make the Editor complain when any new variable renames are performed that would result in new duplicates. However, there is no way (without C++) to create a new Event Graph with the same properties as the default one (e.g. not being renamable or deletable).

Even though it is not clear which situations can result in an EventGraph-less Blueprint, a couple of changes could be made to prevent undesired behaviors:

• When it becomes expected that a blueprint has or does not have an Event Graph, this could be automatically detected and adjusted, for example with FBlueprintEditorUtils::CreateNewGraph() and FBlueprintEditorUtils::AddUbergraphPage(). Alternatively, there could be a way for the user to manually check blueprints for consistency regarding this, and ask that they be fixed when necessary.
• Blueprints without any kind of graph could have another way to make sure that variables never have duplicate names

• Download the repro project from the attachments of the linked UDN case
• Edit blueprint asset "BP_NO_EVENTGRAPH"
• Verify that it derives from PrimaryDataAsset but does not have an EventGraph.
• Verify that variables can be created and renamed without any check for duplicate names.