In addition to potentially stretching textures in undesirable ways, one of the destructive side-effects of this bug is how texture bakes will get messed up because of the triangular holes ripped in the UVs. Stitching torn vertices in the UV editor is unfortunately not very straight forward, and becomes quite tedious for many hard-surface mesh parts. I confirmed the issue existed since at least 2.79b, so it is not a regression. Strangely, it seems increasing the Bevel Modifier's "segments" to an even number like 2 or 4 prevents the issue of split UVs on the angled pieces in my test file, but then the straight pieces still get split UVs, and of course, UV seams are not preserved either (they also get split apart). Having unnecessary UV seams is not ideal for game assets, as the extra seams will increase the vertex cost, and having unnecessary geometry (from extra bevel segments) will also negatively impact performance. It appears the only way to currently mitigate these issues is to set all seams and perform all UV unwraps AFTER the modifiers have been applied. This is a destructive workflow and can also mean an enormous amount of re-unwrapping for detailed hard-surface models that have already been unwrapped.

Yes, you can combine them.

Whether the default values, low or high, I still think it can be merged into the same report T97940: Bevel profile incorrect when using arc for inner miter.
I'm not sure if we need a new report for the case of the value 0.5.
@Howard Trickey (howardt), as a bevel expert, any thoughts on keeping 2 reports? (We still haven't even confirmed if the inter miter's algorithm is really incorrect).

Affect by this change rB21e72496a629: Fix T96728: 'Automatic Constraint' using the wrong orientation
@Germano Cavalcante (mano-wii) ^

This has been reported again, see T98249: Bloated mesh data example (multires CD_MDISPS hanging around without a multires modifier) and actually I think we should reopen this (even if only as a Known Issue)

This mesh_new_from_curve_type_object area is pretty awful, but I think this bug is just about finding the right situations to free original and evaluated data, the fix shouldn't be too bad.

Bisecting points me to rBa7c65ef4cbbd: Fix T96498: Modifiers affect multiple curve objects
@Hans Goudey (HooglyBoogly) , can you look at this report?

Proof that this bug can be fixed in principle:

EDIT: The following information was incorrect: "Additionally, some UV edges generated from applying the Bevel Modifier are left untouched completely and simply get stuffed under the original UV edges". It appears (at least for my test .blend file) the new algorithm in 3.2 is just splitting the bevel operation between the straight and the angled UV islands, rather than keeping the bevel on the angled island (as in 3.1). The rest of the info shared still applies, however.

Thank you so much, @Howard Trickey (howardt) for your work on this! I'm not sure if I've downloaded the correct beta build for 3.2, I have tried the latest 35e73aa3472a but it seems the issue is persisting, except it manifests in a different way than in 3.1.0. Please see attached screenshots and test .blend file. When one applies the Bevel Modifier, different results manifest in 3.1 and 3.2, but neither seems to be correct. I don't believe the bevel modifier should be splitting ANY UVs based on an algorithm, but rather keeping any new generated vertices joined and scaled out evenly from where they originated. It seems the algorithm in 3.2 is currently putting the inner vertex at the center rather than merging it with the one below it, and is separating the outer two vertices rather than merging them at the center. Additionally, some UV edges generated from applying the Bevel Modifier are left untouched completely and simply get stuffed under the original UV edges. I have noted in the final screenshot what should be happening to the vertices. If your fix has already corrected this and it has simply not been applied to the latest 3.2 beta build then I truly apologize!

The UI could need some love here, agree (this is a bit involved though since the operator can act on many different types, not just meshes, metaballs, fonts, ... -- plus it also accepts mixed selections of those...)

Not sure if there is still progress?
In any case, I will step back from reviewing, thx anyways.

We're currently facing this issue again. We have created a small library of Meta Objects and need a way to handle these, collections come to mind, to make sure that changes in the original also propagate to the rest of the new derivates.

Cant redo, but if there is something wrong, it might be related to rB8621fdb10dc4.

Accurate :o
yes, affected by rB8621fdb10dc4: Apply Object Transform: Multi-user data support
cc @Dalai Felinto (dfelinto)

Changing to known-issue, since very distorted N-gons don't define a surface that can necessarily be operated on usefully.

I think this was in Blender since the original implementation in 2.80. It was never fixed.

Oh well you put wrong link (2.79) ignore it. I do use Blender 3.3.0

Hi, thanks for the report. This is likely due to non-manifold geometry.
Your object has intersecting faces, open volume and boolean modifier doesn't work correctly in such cases
This is known limitation as said in:

• https://docs.blender.org/manual/en/latest/modeling/modifiers/generate/booleans.html
• https://docs.blender.org/manual/en/2.79/modeling/modifiers/generate/booleans.html#known-limitations

I'll forward this report to developers in case I'm missing something

Thanks for the information. I'm able to confirm this behavior.
I've also seen that in some cases gizmo doesn't even rotate (eg: in orthographic mode along view axis)
Maybe replace this gizmo with the gizmo of rotation tool?
I'll forward this report to developers as I'm not sure if they consider it as a bug.