I would like to merge this into master now that we are in the early 2.82 stages there. Any objections, Campbell?

Yes, I agree that the crease should be continued across that line. There is the "mark sharp" option that is supposed to fix that, but apparently the code is not handling this case properly.
I will fix this, but probably not until 2.82, because of large pending changes to bevel (GSoC project inclusion) because this is not a regression from previous behavior.

This is not a bug. The Offset mode does not measure width along the edges you are looking at: it measures the perpendicular distance between the offset edge and the original edge. If the edges that it is sliding along happen to make 90 degree angles with the beveled edges, then the perpendicular distance and the distance along the edge will be the same, but not otherwise,

I had put some code in to clamp the sliding amount on "terminal edges" - those where the selection stops at a vertex. That's why you get the clamping result you want when you selected isolated edges. But I really intended one to use the 'clamp overlap' checkbox to cause clamping, and in retrospect I probably shouldn't have done that other clamping even when the box wasn't checked, because it confuses matters about when clamping happens.

In D5516#135587, @Hans Goudey (HooglyBoogly) wrote:

After looking through many of the bevel test results manually, I haven't been able to visually confirm many of the failed operations. The test reports that there is a "Vertex Coordinate Mismatch," but all the vertices I've checked are in the correct locations, and their indexing has been the same as well.
For others the difference doesn't quite make sense. It would be great if someone with more familiar with the automated bevel tests took a look at this; it's not clear to me what the issue is at this point.

Collapsing edges would mostly handle that case, yes. I wasn't sure whether you intended to support that everywhere or just as part of handling merges across boundaries, but thinking about it, you must have meant the former, because the latter wouldn't come up in most cases, if ever.

Pointing out that some of the desire for this comes from the fact that the Bevel modifier can, as a result of clamping, put vertices on top of each other, and users would like them merged. As Campbell points out, the Bevel modifier itself could be changed to detect and merge in such cases. I would have done so if it were easy, but it is not so easy (the current code that merges nearby vertices gets quite complicated), so was delaying -- especially as my eventual goal is to get rid of clamping completely and continue beveling after such collisions cause merges.

I made a first pass at reviewing this. Several minor things to change per my comments.
I think this code is about ready to merge, though we should wait until after the 2.81 stabilizing branch has been made (supposed to be Oct 10).

Thanks for the report.

Eldee, they were pros and cons about the actual-holes-in-faces BMesh solution.

I was about to suggest the same thing eldee said: flagging "support edges" as such, so that the only thing affected is display and selection of edges and perhaps export to file formats that support holes. I too think this is a decent compromise. But it is likely to uncover a number of cases where current code has to be modified to take account of these as hidden, else users will be surprised. E.g., bevel and inset and boolean may all give strange and buggy-looking results if not updated; similarly some select types (e.g., selecting ngons of a given # of sides) will appear buggy unless fixed.

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.