The logic here should be wrapped in a modify_geometry_sets call, and the same geometry set should be used for inputs and outputs. An example of that is in node_geo_mesh_to_points.cc.

Not sure if this was a problem before or not, but the new node can use PROP_DISTANCE for the radius too.

Here you could evaluated directly into the vector, after expanding it so that it's large enough, like

r_positions.reserve(r_positions.size() + domain_size);
...
evaluator.add_with_destination(r_positions.as_mutable_span().take_back(domain_size));

Also, seems this evaluator is named "selection_evaluator" when there is no selection.

Using the same vectors for all geometry sets (there might even be multiple threads working on different instances at the same time) likely won't work.

They should be declared in the modify_geometry_sets function.

Actually, I would recommend moving the modify_geometry_sets loop to the caller, so this function only needs to worry about a single geometry set, that also makes sense since the caller is quite simple currently, it can handle doing a bit more.

Since this geometry set might be part of a "tree" of nested instances, it might have an instance component that contains more points that could be converted to volumes, so keeping GEO_COMPONENT_TYPE_INSTANCES is necessary here too.

This should work a bit more efficiently, since it won't call the virtual array get method separately for every point:

positions->materialize(r_positions.as_mutable_span().take_back(domain_size));

volume is just a raw pointer, so moving it doesn't have any benefit.