I still can't make this happen. Can someone who can make this happen please upload a simple .blend with a cylinder and cube with boolean modifier set to difference where the result of the boolean is the union rather than the difference?

I can't tell how to reproduce this problem. Does the attached blend file (mastering drivers copo.blend) have anything to do with reproducing the bug? From the screenshots, it looks like you are just doing a boolean of a cube with a smaller cylinder. I don't know what it means to say that you have a "wireframe cube" -- do you just mean that the display is set to wireframe? When I try a cube and a cylinder, in wireframe display mode, it works ok for me.

This was committed in rB6f9cbbc8ec4f.

I haven't looked at your patch-on-my-patch yet, but assume it will be ok when I look later, and if so, will submit the modified code. Will also address all of your comments as I commented in response to them, before submitting.

Thanks. I'll look at this. This code got less obviously correct when I put in miters. I already fixed on case like this; guess I didn't get them all.

These are good points, Brecht. And they equally apply to my mesh_ops_test.py and the bevel and boolean tests that use it. So I should revise them too. Or maybe we should just have one file with both mesh ops and modifier test functions in them.

Yes, this is an example of one of the main problems I am hoping to fix with my boolean redesign: that is, when there are coplanar intersections. Thanks for the example; I can use it for testing.

Oh I see.

Booleans on elements other than meshes are out of scope for this task, which is already hard enough. The math and algorithms would be rather different for curve objects. Good to hear that the Curve Cad Tools addon supports boolean operations on curves. Maybe some future design task could consider porting those into the main C code for Blender, if the authors agree.

The committed fix fixes the originally reported bevel problem but not the one added later by arctiq1 with the profile1 cases. That is more complicated and fix for that will have to be a TODO for the future.

Thanks, fixed. (I only found one instance, in the modifier page. Maybe you fixed the other?)

Thanks for the bug report! The bad corner was mistakenly applying the "pipe" code; I fixed the test for a "pipe" to exclude this case.

I do think there is a bug here. Investigating further.

Sorry about that. Now I have added documentation for those two commands to modeling/meshes/editing/normals

I looked at the screw modifier code, and noted that it had code to handle this properly -- it just has to be enabled by enabling the 'Calc order' option in the modifier. So this resolves the problem reported in this bug.
(There remains the similar problem with Extrude, but since that likely needs code like 'calc order' stuff in the screw modifier, which is a fairly extensive change, I will leave that as a future TODO.)

This is working as intended right now (except maybe a problem with clamp overlap -- see below), so I am closing this bug as invalid.

This is a problem with the screw modifier, not bevel.
Edges don't have normals, so this is not a matter of bevel somehow changing the normals of edges.
What does change is the ordering of the vertex indices. This should not matter to the screw modifier -- it should try to make consistent normals no matter what the ordering of the vertices, and it would be too hard a constraint on tools like bevel to try to maintain a consistent vertex ordering (because, for instance, two new vertices are created here), and in general, other tools and modifiers should be made to work despite the internal vertex index ordering.
I will note that a similar problem happens if instead of using a screw modifier, one does an extrude on this line of vertices after beveling a vertex in the middle.

It is a limitation that I don't know how to fix right now. I'm open to ideas. So this is the best I can do.

Yes, the custom normal tools need updating to handle multi-object editing. I'll see if I can do that.

I confirm this. It appears that the mirror modifier is not properly copying the values of the custom split normals.
I will look into this.

Campbell, your fix of putting

layout.operator_context = ‘INVOKE_DEFAULT'

in front of the rotate normals menu entry appears not to work (or at least, work well) when the menu is entered via the Mesh > Normals > Rotate Normals entry.
What happens is that the dotted line that joins the mouse to the cursor is not shown, and the mouse movement causes very limited change in the rotation angle, such that it is hard to even notice that the normals are being rotated.

Is that something settable in the keymap editor? Haven't looked, but will. About to get on a plane for a vacation...

Campbell: When the "Rotate Normals" menu is selected from the Mesh > Normals submenu, it gets a context that has INVOKE in it whereas if it is selected via the same submenu when it pops up after hitting Alt-n (to which it is mapped), it gets a context that has EXEC in it.
.
This means that the operator is INVOKED when you select it from the header menu, but EXECED when you select it from the shortcutted popup menu. Is this intended? It means that the modal operation doesn't happen when selected from the Alt-n menu, rendering this particular operation useless.

Yes, it is not just that the UI doesn't show the connection lines, but that in fact the Rotate option of the menu doesn't work at all -- I guess the modal operation finishes immediately. As a workaround until I fix this, you can use the r shortcut followed by n to rotate the selected normal(s). Or it also works to do an F3 search for Rotate Normals and select that.
But i will work on trying to get the menu method to work. Thanks for the report.

Sorry, there are way too many places in the bevel code where the face normals matter. Now that you bring this up, it is not clear to me that this is necessary, but at some point I thought it was. Since so much other stuff in Blender will not work well if the normals are wonky, it seems like a bit of a fools errand to make bevel work in this case when you are likely to have to fix this anyway later (when texturing & rendering). So for now I am calling the current bevel behavior "working as intended". I may consider trying to undo all the normal assumptions at some point in the future, but this is not an active bug right now.

I confirm this bug. Will work on it.

Thanks for the report. I will look into this soon.

I think that this task is complete for now. We should start a new task for a real tool in the toolbar for a 2.81 or later. Since such tools are typically interactive, some possibilities would be:

• the modal "point normals at" command (maybe with custom gizmo to help)
• the modal "rotate normals" command (currently pretty hidden under rotate transform with n typed afterwards)
• a new modal "set face strength" command, to let you select and set multiple faces' strengths in sequence; ideally combined with custom drawing to show which faces have which strength
• maybe a way to display the numeric values (vector) of selected normals (like a 'measureit' for normals)?

Thanks Philipp for doing such a nice job of isolating the problem. I confirm this problem and am working on it,