"TRIANGLE_FAN" seems a bit odd, what about "TRIANGLES"?

"BMesh-valid" isn't how it should be presented to users, I don't think. Generally users are expected to know the difference between triangles and N-Gons anyway.

This function is quite long, and will only grow in the future. It could be split into a couple sub-functions:

1. Create grouped spline vectors
2. Fill CDT_inputs and do triangulation.
3. Convert the result to a mesh
4. Return the mesh

The curve component should be a reference, since it's always expected to be non-null.

Looks like the size of the result vector is always the size of the number of keys. What about just declaring this after filling "keys"?

Vector<blender::meshintersect::CDT_result<double>> results(keys.size());

This naming is a bit redundant IMO, "i" is almost always an index already.
i_index -> i

const CDT_output_type output_type = (mode == GEO_NODE_CURVE_FILL_MODE_NGONS) ?
                                        CDT_CONSTRAINTS_VALID_BMESH_WITH_HOLES :
                                        CDT_INSIDE_WITH_HOLES;

Also, we can move this out of the loop.

With the change mentioned above, this can be simply results[i_index] = delaunay_2d_calc(input, output_type);

I was looking into removing the use of "Auto" here. It looks like using the same CDT_result in C and C++ for different structs is causing issues. Instead of defining the C result in C++ with extern "C", I think we should only define the C++ result struct.

Is this call really necessary? You just filled the edge vector above. It would be nice to avoid this, since it's usually the most expensive part of creating a mesh.

Instances should either be handled like the point distribute node, or we should realize them with bke::geometry_set_realize_instances

There should be a newline at the end of the file.

Unused now.

I think you could add a size() method to MultiValueMap so you could reserve the proper amount here.

Theoretically if you moved this up above the inner for loop you could avoid reallocating the input arrays for each group index in some cases. What do you think about that?

Okay, I see how there are two indices you're iterating through. Keeping track of an index variable manually isn't ideal though. How about this:

for (const int i_group : range) {
  splines = groups.lookup(keys[i_group]);
  for (const int i_spline : splines.index_range()) {
    ...
  }
}

I know this is a bit nitpicky, but I think it's worth it.

Maybe this is subjective, but I don't really see the need for _ptr at the end of this name, it's clear that spline is a pointer from its type.

Let's add what we talked about as a comment here, something like:
The delaunay triangulation doesn't seem to return all of the necessary edges, even in triangulation mode.

IMO this still doesn't make complete sense, but if we don't understand it we should at least document that uncertainty somewhere for the future.