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.

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).