I am the developer who works on bevel. Unfortunately, this is working as intended right now, though I will try to see if there’s anything I can do to improve it. My best advice here is to use the “Width” method in this situation (though I understand that the original poster doesn’t like that solution).
More than probably most of you want to know:
The problem here is that there are too many constraints that bevel has to satisfy simultaneously in this situation, and it is impossible to satisfy them all, so some compromises are made. Among the constraints are:
- we would like the newly created vertices to slide along the existing non-beveled edges (users kind of expect this)
- the slide distance should depends on the (sine of the) angle between the beveled edge and the slide-along edge – because we want the perpendicular distance to the offset edge to satisfy the offset=amount spec of the user
- there are two angles involved, and their sines may not be equal
- all of these constraints hold at the other end of a beveled edge too, and again, the sines of the angles may be different; yet we would like the width of the offset strips to stay constant along their lengths to the extent possible
Because it is impossible to satisfy all these constraints simultaneously, there are compromise values chosen for how far to slide each vertex along their edges. Then there is an “adjustment” pass that tries to propagate slide the compromises to adjacent edges. That process unfortunately is non-deterministic - it depends on the original ordering of vertices to some extent, though there is an effort to try to chain the propagation together after initial choices are made among connected components of edges. Unfortunately in the model here, different choices of propagation order are chosen for two of the edge chains vs the other two, resulting in different end results.