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.

I found and fixed the problem with the cylinder, with commit rBdd97b09fa8d5 ,

OK, now I see the problem you are talking about and agree that it isn't what I thought (that you just wanted automatic merging of the verts). I suspect that the problem with the cylinder is that the method I use to calculate the vertex positions is numerically sensitive and misbehaving due to using floats instead of double precision. I will see if that is so, and if so, whether or not I can rearrange the calculation somehow to fix.

I confirm this and will fix it. Thanks for the report.

This is just the way bevel works right now, so you are asking for a new feature.
I could solve this by running a 'remove doubles' automatically after doing bevel, and some have asked for that in the past. But I worry about doing that everywhere on the model as it may merge things that the user didn't intend to get merged.
For now, the workaround for you as a user is to do a 'removed doubles' manually after a bevel like this.

Yes, these are limitations of the current algorithm.

Thanks for the patch aiming to improve bevel functionality.

That's a nice idea, Jacques! I could easily implement that, and think I will. Thanks for the suggestion.

This is "working as intended" in that the code doesn't try to be consistent here, and this isn't a regression. It is more like a feature request to come up with a consistency rule.

I fixed this as Brecht suggested, using a separate property for the percentage width offset type.

This fix looks good to me. Can you commit it, or shall I?

Yes, I see the problem. You can work around it by turning off the 'Loop Slide' option.
There's some complicated optimization that goes on to try to even out the loops when loop slide is on, and looks like there might be a bug in that.

Yes, you are correct. I guess the previous CL that I thought fixed things just moved the problem around.
I'll continue to look into this.

This is similar to, probably the same as, the issue discussed in T47129.
Looks like the template has to change to create & copy the CD_BWEIGHT custom data layer. I will look into this.