@Philipp Oeser (lichtwerk), this is something what we should support indeed. Mind looking into this? Shouldn't be hard to add support :)

This is a limitation to the current Particle Instance modifier (not a bug though).

Hi there,

I'll claim for the time being and do some further investiagtion. If that doesnt succeed, I'll get @Bastien Montagne (mont29) on board to help me out...

Confirming on first sight, having a closer look now...

The plan is to improve bmesh boolean to support overlap.

Addons relying on carve modifier are not working in master like this one https://blenderartists.org/forum/showthread.php?409837-Destructive-Extrude-BETA/page9 and the results of bmesh are not yet there in some cases (like overlapping/coplanar edges/faces).
I think it was a very good idea to keep only one version of the boolean modifier and bmesh is really fast, but it should offer as much as the old combination. Or is the plan to only remove functionality in this case?

(Disclaimer: I'm completely new to Blender dev, and I randomly picked this bug to have a look at to try to figure out the code. I've *think* I've tracked it to a certain point, described below, but please use caution when trusting what I say...)

Just saw that "Shapekeys" of a target mesh have no effect in combination with the "Surface Deform"-modifier as well. This modifier really seems to overwrite any other transforms..

can confirm the issue on latest master.

since that was not mentioned,
creases disappear as well

can confirm the weights disappear

If you apply boolean then bevel weight disappear. I tested it on blender-2.79-737a5ef-win64-vc14

please attach a sample file (.blend file, not a video) showing the issue

Bevel weight still not preserved after bmesh boolean. This is especially annoying after removing carve solver, which previously can be used instead

Committed rBd9d3ed16a8c61bb1c780d81a2cf398be92cd16c1

BKE_object_defgroup_index_map_apply now removes all weights with invalid def_nr.
If totweight is zero, it will be freed.

@Philip Holzmann (Foaly) - there is no need to remove them. Just keep the weights that are out of bounds, this is how booleans and object join already work.

@Campbell Barton (campbellbarton) I'm not sure how to do that then.
If we want to keep vertex groups that are out of range, there are different possibilities:

• Map all invalid indices to -1: That could result in a vertex having multiple MDeformWeights with the same def_nr. Also, I don't know if these weights can ever be accessed again.
• Keep all invalid indices: Weights that do not have a mapping to a vertex group in the new mesh keep their def_nr. This means some vertex groups might be merged.
• Keep invalid indices only if they are out of range: Weights that do not have a mapping and are >= totweight are kept. This should not cause problems. But it has to be decided what to do with the weights with valid indices but no mapping, so they don't merge. (Move above totweight or map to -1?)

@Philip Holzmann (Foaly), for now it might be simplest to use old behavior (don't throw away groups which are out of range).
Changes to behavior can backfire so it's sometimes best not to mix them into more general refactoring.

Demonstration File to show that def_nr can be out of bounds, created with Boolean Modifier "Union" in 2.79:

@Campbell Barton (campbellbarton) I guess by clamping you mean the removal of 'invalid' vgroups? I think it’s fine to completely nuke them, I would really not like users relying on such a bad nasty dirty hack to do anything! But as pointed in comments below, I think there is something odd/inconsistent in proposed code regarding this, anyway…

@Campbell Barton (campbellbarton) As Carve boolean has been removed, would it be possible to finalize Bmesh version? Before user could use the other one as fallback, but now we have to use Bmesh. I'm happy to have only one variant if it's robust enough.

MEM_reallocN instead of MEM_reallocN_id.

Minor adjustments

Generally looks good, I'd like to get feedback from @Bastien Montagne (mont29) on clamping.

Vertex Group Merging is now two functions in BKE_object_deform.h.
Used by Array Modifier and join_mesh_single.

Generally OK, although this should be a reusable utility function, it can be added to BKE_object_deform.h call:

I have added a patch, but I don't know if I did it correctly.
If you can see it: Is it okay to fix it that way?