Be careful passing Vector and Array types by value. Since they own their memory, they have to copy all of it in these cases, which might be quite expensive.

That's what Span and Mutable span are for-- to give a view into memory that isn't owned locally.

Unused variable

Calling this splines is a bit confusing, since that's often the name for something like Span<SplinePtr> splines = curve.splines();

Also, I don't think you to manually initialize it here.

You can use .last() instead of end_index

Vector<GeometrySet> & -> MutableSpan<GeometrySet>

Couldn't this part be shared between the two methods?

I doubt this copy is necessary. At least ideally it wouldn't be. const is also somewhat misleading there, since you adjust the data there below. Sometimes which symbol const applies to can be confusing.

Some fussing, this might be a solution:

template<typename T> static void reverse_data(Span<T> src, MutableSpan<T> dst)
{
  for (const int i : dst.index_range()) {
    dst[size - 1 - i] = src[i];
  }
}

    const Spline &src_spline = *src_curve->splines()[merge_map[i].source_spline];
    const int src_size = src_spline.size();

    if (merge_map[i].reverse) {
      reverse_data(src_spline.positions(), dst->positions().slice(dst_point, src_size));
      reverse_data(src_spline.radii(), dst->radii().slice(dst_point, src_size));
      reverse_data(src_spline.tilts(), dst->tilts().slice(dst_point, src_size));
    }
    else {
      dst->positions().slice(dst_point, src_size).copy_from(src_spline.positions());
      dst->radii().slice(dst_point, src_size).copy_from(src_spline.radii());
      dst->tilts().slice(dst_point, src_size).copy_from(src_spline.tilts());
    }

    etc...

Unfortunately this attribute copying code will need to deal with different attribute types and domains on the same names between the input splines, which is a bit of a pain. I'd recommend dealing with that last.

Looks like these aren't used.

Unrelated formatting changes

No need for the newline between the comment and the definition.

The template is already part of the class, no need to have it on member functions.

In C++ the typedef is unnecessary, so it can look like this:

struct MergeMapEntry {
  int target_spline;
  int source_set;
  int source_spline;
  int length;
  int attr_start;
  bool reverse;
};

I also think these should be defined after the inputs, layout, init update functions.

A more C++ style way to do this: enum class MapStatus { Okay, None, Mixed };

Then you can refer to them like MapStatus::Mixed

It's simpler to call spline.size() I think.

spline_list.append()

Something I've learned from Jacques and others is that if a chunk of code seems like it needs a header comment block like /* Build the KD Tree. */, it's a good sign it could just be split into a separate function with a descriptive name like KDTree_3d *build_kdtree_from_spline_endpoints(...)

Then the code documents itself, and it's easier to read since it's more clear which parameters the tree building needs, and you can more easily get a high-level view of the whole algorithm.

Generally one should be careful about calling insert on a Vector, since if the index isn't the last, it will have to move every element after the index, which can be slow.
In this case, append should work well.

output_spline_number -> output_spline_index

I'd recommend splitting this to a separate function too.

Is this necessary? If the size of a span is 1, first() and last() should be equal.

I think this has to be freed unfortunately.

I think this could be implemented with BLI_kdtree_3d_range_search_cb so that a results array wouldn't have to be allocated for every end point encountered in this loop.
The point distribute node has an example.

spline_index_from_endpoint makes me a bit skeptical. Maybe it's necessary, but traversing the whole list for every result is O(n^2) behavior that we should aim not to have.

I think this can make use of the fact that it doesn't run for mixed spline types and call spline->copy_only_settings();

The value of point_count is assigned but not used, it could just be removed.

This is still an issue:

/home/hans/Blender-Git/blender/source/blender/blenlib/BLI_span.hh:737:12: error: declaration of template parameter ‘T’ shadows template parameter
  737 |   template<typename T> constexpr void copy_from_reversed(Span<T> src)
      |            ^~~~~~~~
/home/hans/Blender-Git/blender/source/blender/blenlib/BLI_span.hh:470:10: note: template parameter ‘T’ declared here
  470 | template<typename T> class MutableSpan {
      |          ^~~~~~~~
/home/hans/Blender-Git/blender/source/blender/blenlib/BLI_span.hh:745:12: error: declaration of template parameter ‘T’ shadows template parameter
  745 |   template<typename T> constexpr void copy_from_reversed(MutableSpan<T> src)
      |            ^~~~~~~~
/home/hans/Blender-Git/blender/source/blender/blenlib/BLI_span.hh:470:10: note: template parameter ‘T’ declared here
  470 | template<typename T> class MutableSpan {
      |          ^~~~~~~~

This can use PROP_DISTANCE

Another comment here that hasn't been addressed.

This is marked "Done" but I don't think it was addressed. I would suggest the BLI_kdtree_3d_range_search_cb approach since that might allow an early exit in addition to the lack of allocations.

==124164==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 13009920 byte(s) in 9240 object(s) allocated from:
    #0 0x7f6ab4f6793f in __interceptor_malloc (/lib64/libasan.so.6+0xae93f)
    #1 0x866591f in MEM_lockfree_mallocN /home/hans/Blender-Git/blender/intern/guardedalloc/intern/mallocn_lockfree_impl.c:277
    #2 0x86652c3 in MEM_lockfree_reallocN_id /home/hans/Blender-Git/blender/intern/guardedalloc/intern/mallocn_lockfree_impl.c:183
    #3 0x828cf4d in nearest_add_in_range /home/hans/Blender-Git/blender/source/blender/blenlib/intern/kdtree_impl.h:628
    #4 0x828e1fa in BLI_kdtree_3d_range_search_with_len_squared_cb /home/hans/Blender-Git/blender/source/blender/blenlib/intern/kdtree_impl.h:696
    #5 0x828e7d6 in BLI_kdtree_3d_range_search /home/hans/Blender-Git/blender/source/blender/blenlib/intern/kdtree_impl.h:731
    #6 0x3927e33 in merge_map_threshold /home/hans/Blender-Git/blender/source/blender/nodes/geometry/nodes/node_geo_curve_connect_splines.cc:233
    #7 0x3932cb7 in geo_node_curve_connect_splines_exec /home/hans/Blender-Git/blender/source/blender/nodes/geometry/nodes/node_geo_curve_connect_splines.cc:471

Did you have thoughts about this? I think the code is still the same. O(n^2) algorithms can be pretty dangerous when the problem starts to scale a bit.