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.

I put this in my draw_cache_impl_mesh.c so that I could turn on #define of USE_BM_MAPPED_LOOPNORMAL and get it to use custom loop normals properly in display.

Campbell, your recent commit rBff3601b9 seems to have broken some of the code that was written to fix this, or maybe just broke the code that fetches and uses custom normals in shading. Now when autosmooth is on it doesn't seem like the workbench display uses custom normals at all (e.g., trying to modify them with the mesh -> normals -> point normals to target command, using m for mouse -- nothing happens now).

Yes, this seems to have been fixed by commit rB18f0618677 (found by bisecting commits). I'll close this bug.

The main bug (#1) is fixed now, but still have to fix the problem where the bevel operator run from Python cannot harden normals,

Somehow the memory allocator data structures got corrupted so that it returned the same value for both the edge pool and the loop pool allocations (!).
I'll have to did deeper to understand which code is doing the corrupting. I tried Valgrind, but no luck.

The problem is that the BKE_mesh_to_bmesh_ex() appears not to have created a bm->epool with the BLI_MEMPOOL_ALLOW_ITER flag set. I'll dig into why...

The proper thing to do is to share the normal hardening code by putting it in BM_mesh_bevel(), rather than the current strange mix of having some of the work done in that function but most of it done (separately implemented) in the modifier and in the editmesh code that runs after the BMOp bevel runs.

OK, so the crash was because one also needs to do a bmesh.update_edit_mesh(C.object.data) after running the above commands, and it is documented that one needs to do so. It all seems to work fine (though without hardening normals, if that is specified in the arguments) now.

does what is required to prevent the crash and have the new mesh properly displayed.

Crash is an assert in GPU_indexbuf_add_generic_vert, where it is trying to add a vertex to an index buffer that isn't big enough.

The immediate problem was that no verts were in the input geometry, and code assumed that if edges were there then verts were there. The code in the second update added the verts. But I fixed the code to add the verts from all edges explicitly so that this would no longer be necessary.

Indeed, it was a type for Loop variable. Thanks. Fixed now.

I too confirm the crash and will work on fixing it.

This needs to be corrected in the documentation. I will do so.

I'm not sure if this should be assigned to Clement, Campbell, or someone else. Also not sure if this is a bug that is intended to be fixed before the beta.

Thanks for bug and example. I will look at how to fix this.

As mentor for this project, and general Bevel maintainer, I will do this documentation, so you can assign this task to me.
If I understand correctly, 2.8 docs are not yet being committed. If that is right, where should I (right now) write/save the docs that I do for this task?

You are not being a nuisance. I appreciate hearing about the real-world problems people have. This is unfortunately another example of the harder part of your original report -- getting a more global consistency. I have a vague idea of some rules that might help, but have to think through some more.

Thanks for the gif. It helps confirm that I understood what was bothering you, and what would make you happy (or, happier). And it should be easier to fix that than to produce exactly your ideal results.

I've looked at this some now.
There is no quick, easy fix. So this will take some thinking.
The problem is that we have to decide which side of a seam to put the bevel parts on. In the provided example, the side has been chosen consistently so that there is pleasing overall symmetry. I need to see if I can think of an algorithm that has that effect.
In addition, there are the triangular corners that now get mapped to go only halfway across their adjacent edges. I'm not sure why that is. Needs more debugging. Bug also not clear if just having them extend all the way across the adjacent edge would satisfy the bug reporter.

Thanks for the report. Will look at fixing this problem soon,

After talking with Campbell, have decided to close this one for now. If we can reproduce that second issue in 2.8, then can reopen with a repeatable test case (using script or knife project).

There are two things going on here and I am not sure which you are trying to report.

As a further note, this problem also appears to be in the 2.8 branch (using F6 to bring up tool settings after an initial bevel with control-B, and trying to change segments, on the example pp.blend file).

Yes, this is now resolved. Closing.

Thanks for the report. I can confirm too, and will fix. This was an unintended change when I made the last fix to Bevel. As Philipp said, a workaround until fixed is to turn off loop slide.

Despite this having been closed, I still intend to spend some cycles seeing if I can make the bmesh solver handle at least some of the coplanar cases. Carve seems to have worked sometimes but not consistently - from what I can read, it is not claimed that it works in those cases but I guess sometimes it did. The algorithm Carve used was completely different from that used in the BMesh code, so pretty hard to just adapt the parts that may have been solving the coplanar problems. As to why not just leave Carve as a backup: existing developers got tire of all the bug reports against Carve (crashes, not working in certain cases); combine that with the general difficulty of dealing with external libraries (dependencies, versions, hard to push fixes upstream, rot when new compiler versions don't work, ...) led to the decision to remove Carve now that BMesh boolean does pretty well in the general (non-coplanar problem) case.

This is not something the current bmesh boolean code was intended to handle (coplanar intersections). So one could say that this behavior is "working as intended" (where "intended" = "undefined" in this case). The user can, of course, move one of the planes very slightly to get it into "defined" territory, but understood that that is tedious for the user especially if there are a lot of things that need to move and no easy single command to find and move all of them at once. So I will take this task assigned to me to see if something can be done, but there is not likely to be a quick fix to this.

Finally fixed the profile=1.0 case with commit rBbd9ed0228b84, removing a bunch of the most requested tasks in this design task.

I don't see this problem any more (in master compiled today), so I'm closing this bug. Feel free to reopen if I've misinterpreted.

This was fixed a while ago, with smarter clamping code.

Recent commit rB561d738eaa2f also fixed this.

Better clamping code is now in, and the original model in this report is now OK.

Whatever the problem was here, it seems to no longer be a problem in the current 2.79 release, so closing this.

This is a valid problem, but one that the current algorithm for handling profile=1 is not capable of solving. I need a new algorithm for that case, or more special cases. This is already a TODO on the general Bevel Improvements task, T48583, so I am closing this instance of the problem.

This is a valid problem, but one that the current algorithm for handling profile=1 is not capable of solving. I need a new algorithm for that case, or more special cases. This is already a TODO on the general Bevel Improvements task, T48583, so I am closing this instance of the problem.

Several more bugs reports have also been about the behavior with profile=1.0. As mentioned above, this is difficult to fix in general but likely I should work on some more special cases. I'm going to close the bugs T51010 and T53783 as they are grouped under this general TODO.

Unfortunately, it is not the last known one for bevel. I'm currently working on T53459, which is taking a lot of effort to fix (end is in sight, though).
For this bug, as mentioned earlier, the problem is that I don't understand the theory of subdivision with constraints on boundary normals well enough to make the general case ensure curvature continuity.

I am happy to change the code for Bevel and Inset to allow spacebar for confirm. Just wanted to check with someone else (Campbell?) that this is indeed a UI pattern that Blender is intended to have.

The mesh isn't corrupted. But it does hit a non-determinism in the current algorithm. Here is what I wrote on that thread, which shows my current understanding of this bug:

Yes, I see what you mean. I will look into it.

The given test file now imports, though probably not in a satsifying way for you. This importer only pays attention to vector geometry that forms closed polygons, and the imported file has images and / or bare edges for most of the interesting stuff.
Thanks for the report. Always good to fix crashes!

I confirm the crash and will look at this.