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,

Currently the normals menu commands all have a poll that tests for autosmooth being on. That poll should be removed and the code should just test and turn it on if not already on when those menu items are invoked. I looked once at doing this automatically in the bevel modifier when harden normals was chosen but it was annoying to do because the bevel code is all in a file that only operates on BMesh and there is no autosmooth option recorded in BMesh that could be set and propagated back to the Mesh in the modifier code. This could be corrected, of course.

One question about the idea of making the normal vector in the transform tools item panel be a live reflection of the current selection: this is a not-inexpensive operation (see BM_loop_normal_editdata_array_init in bmesh_mesh.c: it allocates several #loop-length things and iterates over all the loops of the mesh). Even if we only do this if there are custom normals, is there any concern about doing this every time a selection changes? I don't think so, but wonder what others think before going down this coding path.

@William Reynish (billreynish) Yes, I can see that (the copy/paste buffer being elsewhere and hidden).
What were the thoughts about Add/Multiply? Dump them?

I agree with most of this, and have been working on it. With changes I made to the normal menu, I can now remove Face Strength from the Normals panel in Tool properties.

Thanks for the fix. I will apply and commit this shortly.

This looks good now. I agree with you that the weight <=0 case cannot occur at that point in the code.
I've submitted these changes now, with rB3e780507bd6 .
Thanks for your help on this!

Why did you move the weight transfer stuff for vertex_only down? It seems that it now moves it past the point where the BM_ELEM tags were needed and set/unset.

This looks good. Thanks for doing this. The solution for what to do about 'width' seems like the best approximate solution to a somewhat undefined problem.

One things that changes everywhere in the manual are the parts where it lists where various buttons and other UI live. E.g., most things that were on the tool shelf are listed as being on Panel Tool Shelf > Tools.

This is somewhere between a bug and a feature request. The width type was intended for, and explained by, its effect on the amount an edge is beveled. But I can try to think of what to do for vertex. Seems reasonably clear for depth type but less clear for width type.

I can't reproduce this. I've been updating bevel_regression.blend pretty regularly (last time Feb 11) and it passes for me.
This is what I do on MacOs:
(with Debug build)
build with lastest master
test with latest svn revision of tests
in the build directory run:
ctest -C Debug -R bevel
and it runs that bevel test and shows it passing.
Similarly if I "make test" on Linux.

p.s., I realize that the stack trace in the intial report is during the heart of bevel. My crash happens much earlier, as the previous note said. Perhaps because it is a Debug build? My stack trace:

This happens at the very beginning of the bevel modifier's applyModifier function, before bevel actually does anything, when it is trying to do BKE_mesh_to_bmesh_ex() to convert the input into a BMesh. So I don't think this has anything to do with Bevel, but rather some kind of corruption in the input file or something gone wrong in the generic mesh to bmesh conversion procedure. I can look into this further but not right away. Is there someone better than me to look at this?

The problem is not with bevel, really. It is that right-click to cancel extrude doesn't cancel it -- it just sets extrude amount to 0. So we end up with two faces on top connected with zero-length edges. This is not a situation for which bevel is intended to work well.

This was not really releated to harden_normals, but rather that the algorithm used when loop slide was enabled could give different results from run-to-run. I fixed that.

OK, I finally found time to look at this. Unfortunately, I am going to close this as "working as intended". The workaround cited above (turn off Loop Slide) should be satisfactory in cases like this.

I take it you are interested in making a proposal for the exporter idea for GSoC '19?
I will try this out soon. Am very interested in what the speed comparisons are so far with this vs Python export. Did you do any measurements of that yet?

Improvements to the profile=1 case have fixed this, so closing this bug.

Rohan's GSoC fix did indeed fix this particular case and is now in master, so closing this bug.

Clearing out old bugs. Clamping is currently working as intended, even if not ideal. The long term fix is to actually have the geometry merge and/or otherwise do intelligent things when collision happens, and then remove 'Clamp' completely. I hope to get to that as my next big bevel improvement project, though it is some time off.

Closing this now that Bevel has a user editable keymap, so users can map spacebar to confirm if that's what they want.

Sorry, I am closing this as "working as intended" because the code is doing what I intended: that is, it is choosing to keep widths even along their edges as a higher priority than trying to half-way meet an unmeetable set of width constraints.

The behavior in 2.79 is not really intended -- it is more an accidental consequence of a choice made to solve conflicting specifications.
What the specifications say is that one edge is supposed to have one particular bevel width all the way along it, and the other edge (with the adjusting weight) is supposed to have another weight all the way along it. Where they meet is a conflict. The conflict used to be solved by taking an average, which gave the smooth tapering effect you saw. But for other cases (especially when there are loops) that is not nearly good enough, so I switched to using a least-squares optimization some time in the 2.79 series (I see that you note that this was working for a while in 2.79 and then stopped working, so maybe that was when I made this switch).

Even though the behavior is surprising, even to me, I am closing this bug for now as "working as intended", since the semantics of vertex groups and weights being interpolated is indeed as intended. I will add a point in my general bevel improvements request bug, T48583, to eventually fix this.

Added Campbell to get his opinion too on how to solve this problem with vertex groups being used for membership and interpolation.

OK, this was mysterious, but I understand the problem now. It is that vertex groups are getting mixed up in a way that is likely unexpected to users: there are weights associated with each vertex in a group and the bevel modifier considers each vertex to be part of the bevel if the weight is >= 0.5.

I confirm too for 2.8. Oddly, it only happens for the modifier, not the tool (oddly because the code for the core bevel is the same). And the second bevel doesn't have to have 0.5 width -- any width will show the problem as long as the first one had width 0.5. I will investigate further.

I am not sure whether I did anything in particular to fix the mouse sensitivity to percent, but it seems fine to me. Maybe this also had to do with the scale issue that my commit did fix. If the original reporter of this bug thinks it is still not ok for percent, please give more details (a .blend, and details about what you did -- I'm assuming adjusting by mouse movement, but maybe that was a wrong assumption).

I fixed this with rB208fafb

This is caused by the recent commit by Campbell, rB8a432c1a4 , which put a lookup using op->ptr into initTransInfo. But that function is sometimes called with a null op (inset and bevel do it to find the geometric center to draw the UI dotted line from). Not sure if the right fix is to pass op down through the stack from those two places, or to protect the newly added code by "if (op)", so asking Campbell to figure out the right fix. If this is urgent to fix, we could put in the "if (op)" tests now until Campbell can get to it.

Confirmed. Working on it.

Thanks, I will look at this.

I will fix this by splitting, which will also make it possible to do units right (have already done this splitting in the modifier).

The merged-in T61709 is a somewhat different problem, but I'll address it as part of this task. In that task, it is just doing an outright wrong UV assignment in the supplied example.

Yes, this is for me to fix. I wasn't quite sure of what the 'release confirms' was for, but now I do.