Update to resolve feedback from previous revision and suggesions from chat

Some other areas I encountered that may benefit from further discussion:

I do feel the new volume functions may have too many parameters, that is one of the reasons why I made BKE_volume_compute_voxel_size "public" so that BKE_mesh_to_volume wouldn't need the depsgraph, boundbox, resolution parameters.
Perhaps using a struct for the fill_volume, exterior & interior parameters makes sense. Then perhaps the voxel_size function can be called inside mesh_to_volume like it was originally.

I have made some progress on adding a MeshToVolume node using the modifier and VolumeToMesh node as a guide. I need to review the feedback about D10506 in more detail as I have likely encountered similar issues. Hopefully I can provide my changes for feedback soon.

Yes @Himanshi Kalra (calra) I did do exactly what you mentioned. I placed a breakpoint on the return and viewed mesh in Watch 1 and result in Watch 2 (Visual Studio). This only showed data for the first edge but luckily that was different anyway. I then played with a natvis config so I could view all the edge data in the debugger.

No code changes, added more context to the diff

Hi, I compared the original Mesh data with results from the earlier BMesh fix and noticed differences in the MEdge.flags. The flags were not set in the original code but adding ME_EDGEDRAW looks to resolve this issue.

I was expecting feedback as this was my first time working with the blender codebase. The intention behind the separate function was if it could be used in other places and I wondered if linux or mac should have an implementation. It may also be worth reviewing if the regular delete functionality handles long paths too.

I had a quick look at IFileOperation and was unsure regarding the single threaded/multi threaded apartment notes so went with older method, I hadn't considered the path limitation.