See also

• some minor ui fixes and default setting tweaks

So... what was the point of migrating the modifier UI code from python back to C in 2.90 again ?!
Making external devs angry ?
You sacrifice a lot of flexibility having UI code being run in python for some drag and drop eye candy ? seriously ?!
That is a big step backwards imho. Now i would need to backport the UI code to C... yuck... tried that. But what about the template_list() function ?
Its C equivalent needs a Context pointer. Great... one of those you never have handy at your disposal.
Where does it come from in the python function ? USE_FUNC_CONTEXT looks like a big automagically stuff... In that state i am unable to update the UI code and the patch for 2.90.
And the code really should not fail because of some UI stuff.
Some easy to find documentation / migration guide for that imho totally unnecessary UI code policy thing would have also helped.
and better function names, not uiItemR and stuff like that... and really, UI code belongs into the python part.

hrm, i better should NOT have rebased my arcpatch branch to master before... lol... now there are unrelated changes in here as well (weld modifier stuff, curve stuff etc)
but the wiki docs regarding arcanist and arc diff (aka updating your diff) recommended that.

• attempt to perform all review related changes

In D4960#174875, @Brecht Van Lommel (brecht) wrote:

Move to separate Voxel Mesher modifier, in case this would have taken a lot of time.

@Pablo Dobarro (pablodp606) First, thanks for your help :)

So, but the voxelremesh operator lacks CSG functionality, filters, as well as texture / material transfer, and the preserve Hard edges support. And not yet speaking of the ability to mesh particles. Should this be part of the operator then too ? So both the modifier and the operator can share a common codebase ? Either way, I disagree here that is just a little bit of work. I would estimate it is not rocket science, but not too trivial either.
Means I just need a bigger slot of time in order to do the required changes. Not sure whether other devs could do this faster, because they would need to read their way thru the code on their own or ask me for help in order to accelerate this a bit.

Ok, what about:

In D4960#170364, @Brecht Van Lommel (brecht) wrote:

Regarding the volume object, I think that is separate functionality. In the future we will likely have a node for converting a mesh to a volume, a node for doing volume boolean ops and a node for converting a volume to a mesh. But we don't have that yet, and even if we did this is still functionality we want to provide with an easy interface.

some more pre-review cleanup, aka removing unintended changes

dead code cleanup and clang formatting of patch

Update of diff for recent 2.83 master, no functional changes.
@Brecht Van Lommel (brecht) I would like a review for this to be included in 2.83

in order for the ModifierList addon to show the CSG UI elements, i think the highlighted python code (from modifiers drawing code) must be added to the addon too.
Or atleast the operator names should be made known to the addon.
And for the skin modifier as CSG operand, seems to work here. If the original CSG object is set to Textured, it will just hide the remeshed part I think, so it should be hidden in viewport or render.
Theoretically "reproject data" should transfer UVs or materials too, from the skin modifier original object to the remeshed part (tho there are seam issues still)

@paul geraskin (mifth) Hmmm, i am not sure yet how to implement this. Vertexcolors or weights would need to manipulate the filtering in openvdb somehow...

Added custom data reprojection for UVs and materials (for some reason, vertex and edge data doesnt work so well with it, using datatransfer code)

Tried to patch this, but the more I dig into it, the more questions arise, lol...
For example what on earth has "Overrides" to do with copying something on RNA level ? Is that the same as Static / Dynamic Override (which never was finished up to now) or something different with the same name ?
Lol... Anyways, I will share here my partially working patch, but it wont copy the Custom Profile, just re-assign it to the other modifier. Probably this is some corner case with Pointer Properties, which are not meant to be copied but to be assigned somewhere else only. But this doesnt work here. In case one of the other bevel modifier objects is deleted, blender will crash.
Probably, in order to make the CurveProfile more re-usable and copy-able (in one go) , it must become some separate ID which can be linked into the bevel modifier, like a cachefile is linked into the Meshcachesequence modifier or Particle Settings are being linked into a Particle System Modifier.

@Hans Goudey (HooglyBoogly)
Thanks, the custom_profile.update() call seems to work. But the target curve's widget looks often a bit weird afterwards, aka weird triangular artifacts.

Hmm, seems this is no simple oneliner in order to fix this issue.
After some search in the code and some debugging, i found out that here
https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/interface/interface_context_menu.c$543
but->rnapoin.data && but->rnaprop seem not to be set (if you rightclick on the curve in the bevel modifier).
The curve is defined here basically
https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/interface/interface_templates.c$4959
but there is no uiBut (no button) inside the curve area itself one could bind the context menu entries to. Its just an uiBlock, which works differently.
The rnapoin and rnaprop data is handled by a callback here, RNAUpdateCb.
Bottom line, it seems (for me atleast, who is unfamiliar to that code area) not so super easy to fix this properly.
Maybe one would need to write a custom (mass) copy operator which iterates over the curve points / handles or so. But i dont think those are exposed via python,
so this needs to be done in C.

@Lukas Stockner (lukasstockner97) Hi, feel free to commit the patch :) I am busy with other work and a bit out of the loop atm.

Hmm, didnt actually check the code, but it possibly draws triangles in sculpt mode due to usage of MLoopTris instead of MFace, aka triangle only mesh representation vs tri and quad like before.
( I doubt sculpting supports ngons and polys directly, but i could be wrong here.) Could also be the drawing code does own triangulation there.

Tried the provided blend with 76650402f300 and a master version from september 13th.
Except maybe the extraneous green dot "far away" from the active vertex I also had no flicker or locking.
Windows 10 Pro 64-bit
Intel UHD 620 (laptop) (Lol, a miracle 2.8 seems to run flawlessly with this hardware :) )

improved sharpening mode : usable for csg objects and now threaded with tbb::parallel_for