The latest Spine Runtime for UE4 still has these two issues.
1: Memory Leak in SpineSlateMaterialBrush

struct SpineSlateMaterialBrush : public FSlateBrush {
SpineSlateMaterialBrush(class UMaterialInterface &InMaterial, const FVector2D &InImageSize)
: FSlateBrush(ESlateBrushDrawType::Image, FName(TEXT("None")), FMargin(0), ESlateBrushTileType::NoTile, ESlateBrushImageType::FullColor, InImageSize, FLinearColor::White, &InMaterial) {

           // Workaround for https://github.com/EsotericSoftware/spine-runtimes/issues/2006
            FString brushName = TEXT("spineslatebrush");
            brushName.AppendInt(brushNameId++);
            ResourceName = FName(brushName);
            // The above code causes an infinite increase in FName entries, leading to uncontrolled memory growth in UE,
            // eventually causing an out-of-memory crash.
            // No fix code is provided here as my solution is temporary.
            // Just a complaint—if you don't understand UE4, don't mess around with the code!

}

};

2: Crash due to Wild Pointer When Switching Spine Animations
File: SpineSkeletonAnimationComponent.cpp
void callback(AnimationState *state, spine::EventType type, TrackEntry *entry, Event *event) {
USpineSkeletonAnimationComponent *component = (USpineSkeletonAnimationComponent *)
state->getRendererObject();

if (entry->getRendererObject()) {
	UTrackEntry *uEntry = (UTrackEntry *) entry->getRendererObject();
            // Warning: `uEntry` may be a wild pointer!
	......
}

}
Root Cause:
UTrackEntry and TrackEntry hold mutual pointer references. However, since UTrackEntry is managed by UE's garbage collection system, it is not immediately destroyed when no longer used. This leads to scenarios where TrackEntry holds a dangling pointer to UTrackEntry, causing a crash when accessed.

Impact:
This crash can occur in both Widget-based animations and Scene-based animations.

Fix Approach:

When TrackEntry is deleted, it must remove the reference to UTrackEntry.
When UTrackEntry is no longer needed (note: not deleted immediately), it must remove the reference to TrackEntry.

Related Discussions
...

The issues you've described with the Spine Runtime for UE4 are indeed critical. The first issue involves a memory leak in SpineSlateMaterialBrush due to the continuous creation of FName entries, which can lead to an out-of-memory crash. This is a known issue, as referenced in issue #2006. A potential workaround could involve managing the FName entries more efficiently to prevent uncontrolled growth.

The second issue involves a crash due to a wild pointer when switching Spine animations. This is caused by the mutual pointer references between UTrackEntry and TrackEntry, where UTrackEntry is managed by UE's garbage collection system. To address this, you should ensure that when TrackEntry is deleted, it removes its reference to UTrackEntry, and similarly, when UTrackEntry is no longer needed, it should remove its reference to TrackEntry. This approach should help prevent crashes due to dangling pointers.