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.

Now that Campbell has taken the GSoC 2016 PBVH project into master, this task can be closed.

Thanks, can confirm that that happens now.

I agree it is weird, though sometimes things like this happen because it is impossible to simultaneously set the bevels for all edges to what they should be mathematically (due to interactions with the bevels at other edges, and the code tries to "compromise" in cases like that). But I need to investigate more to see if that's what is going on here.

I am pretty sure this is not a bevel bug. I tried installing and running your testBugAddon.py (on Linux), and while it didn't crash, it did produce error messages like:

Strange, it works fine for me on Linux. I will try on Windows when I get a chance and see if I can reproduce there.

Thanks for your suggestion, Jac. And thanks for the clear examples in your rightclickselect post. While it seems strange to me to have a different treatment of seams for odd and even numbers of segments, I can understand your argument. What about other edge attributes (e.g., smoothness; bevel weight; ...). In your opinion, which edge attributes should go exclusively to the middle edge, which should go to all of the edges, and which should go to the outer edges of a beveled edge?

Yes, looks like that would work. I will wait for D2724 to be merged.

Hmm, not sure what to do about this.

The fix just committed only fixes this bug if the 'Clamp overlap' option is enabled. The fact that sometimes the existing code stops the edge slides when it hits another vertex was not something that was intended to find and fix all geometry collisions. Even 'Clamp overlap' doesn't do that, though it tries harder.

Someone else requested something similar to what you suggest -- just that when some vertices get blocked, they stay there and the unblocked ones continue to move. Maybe this should be the default, but I'd like to get some kind of consensus from artists before changing. As you say, it could be an option, but there is a lot of pushback on Blender devs from Ton not to add too many options to tools, but rather make them smart enough to "do the right thing" without options.

Sorry it took so long to fix. Thanks for the report. It is fixed in the blender-addons-contrib repository.

The problem is that the clamping is very naive right now: just clamps to the min of the half-length of all the edges involved in a vertex bevel. In this case, that means it clamps to the half length of the vertical edge, which doesn't even have advancing vertices on it, and it is a lot shorter than the edge that the vertices move along. It is a TODO to do much smarter clamping, but I'll spend some time now to see if cases like this, at least, can be improved.

This is different from T50994, as it is only about one edge (as reporter notes). It may overlap with one of the problems reported in T50819, premature clamping. I will look into this one now.

Another requested bevel clamping change. See T50994. Requester would like clamp to apply to edges individually rather than globally. Could be consider as breaking backward compatibility for 2.8. Or an option (but we dislike adding too many options).

Sorry, the behavior mentioned here in this bug (T50994) is the intended behavior. The clamp that is calculated is a GLOBAL clamp for the offset amount, calculated as the minimum amount that might cause overlap (approximately -- doing it exactly is hard, and a TODO). The reason for this is so that the bevel looks uniform when done -- that is, the widths all look about the same. In some artistic contexts, it could look strange to have some edges beveled a lot and some edges beveled a little (e.g., you might want all edges of a table beveled approximately the same).