Descriptions should be phrased positively, so without the "when this is true"

Maybe you have a better idea, but something like Keep non-manifold boundaries of the input mesh in place by avoiding the dual transformation there could work.

I'd suggest calling this Dual Mesh. Even though it repeats the node name-- I think it's also important that the socket name be descriptive.

Replace with data.copy_from

Unfortunately there is one more case: face corner domain attributes. Since face domain attributes are moved to vertices, it's a little hard to know what to do. I'm not sure, but it looks to me like there's a 1-1 correspondence between the face corners in the input and in the output. Does that make sense?

It's definitely subjective, but I'd suggest a convention I've been using for this sort of copying function recently-- src and dst or src_attribute and dst_attribute. That way it's clear every time which is which. Or some other variation of that, or no change at all. Just something to consider.

++ is a little shorter here.

Also, I know I recommended a shorter integer type here, but I realized that might be problematic if a vertex is connected to more than 256 edges. I guess a fix would be avoiding the addition if it's already 3 or greater.

I'd suggest a more self-documenting name than "preprocess"

I'm probably missing something here, but isn't it expected that vertices only connected to two polygons will be boundary vertices? I'm just wondering if the checks are redundant with the information provided from the caller.

Declare variables where they are first used.

This isn't really a request for a change, but just a question:

I was looking at this loop, which is quite large at this point, wondering about multi-threading. Looks like much of it is hard to do in parallel, but this sort_vertex_polys looks like it could be done in parallel, and it seems like a fairly expensive part of the algorithm. The downside would be having to allocate space for all of the edges at the beginning. So I'd guess-- probably worth it, but correctness may be more important for now.

Instead of reusing the variables here, it might be more readable to declare them const and give them descriptive names.

That was what I did first, but it complains about the sizes not being the same.

Sadly this is not the case. Even in Suzanne there is vertex not on the boundary connected to only two faces. An example is something like this:

So the idea would be to do a parallel_for on the vertex_poly_indices array to sort the polygons in parallel before this loop? I think that makes sense, but would indeed need an extra allocation for all the edges.

Ah right. In that case, if you like, you can use dst.take_front(src.size()).copy_from(src)

Makes sense. Thanks!

Yeah, right. Maybe it's best to try that as a separate step after this is finished.

There is again a pathological case that I'm referring to here (see image). The orientation of the central n-gon in the dual is determined by the orientation of the polygon which gets chosen as first. In the top circle the orientation of the first polygon (index 4) is red, so the central n-gon is red. For the bottom circle the orientation of the first polygon (index 0) is blue, so the central n-gon is blue. For the boundaries, the same thing applies, although the situation is a little bit different here because the first polygon needs to have a boundary edge.

TLDR: If the polygons around a vertex have inconsistent orientations, then the resulting polygon will pretty much have a random orientation.

I was using MEdge because it lets me 'transfer' things like sharp and seam edges. Not sure if we should just ignore those completely.