Mmmh… in fact there is no bug here, even though the result may not be what one would expect off hands.

Edge group for bevel could be better than vertex group

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.

I think what I'd like to see is a threshold that prevents close vertices from overlapping without blocking the movement of vertices that are far from each other. I suppose something like a weighting that diminishes the bevel effect for close vertices.
Something like in the following which shows how Edge-Slide has less impact on close vertices but a large influence on vertices with larger distances. I think this would have to be an option though since it would best suit organic or choppy shapes like rocks. It would likely be inappropriate for machined surfaces.

For a much simpler testcase, apparently demonstrating the same problem -- non-solid objects resulting from boolean difference with BMesh -- see T51236 . Again, "Carve" produces the correct result, "BMesh" doesn't.

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

But shouldn't a mesh generated by a fluid sim be closed and non-self intersecting?

@Howard Trickey (howardt), mind having a look here? Thanks! :)

This is not about depsgraph, it is about some internal conventions which depsgraph have nothing to do about.

Thanks for the report, but nothing to be done here currently really, this is known limitation of boolean ops - they need sane meshes as operand, that is, meshes that are closed, not self-intersecting, etc. Better handling of corner cases and complex situations is considered a TODO currently, not a bug.

in bli_winstuff.h we replace the stock fseek function with a 64 bit version

whitespace fix

From an end-user standpoint I would expect the object to curve along the visible (final/deformed) curve rather than its base geometry. If that was unwanted I could still duplicate the curve and remove the shrinkwrap modifier. With the current behavior I am prevented from choosing a possible option.

I think it's more a design problem than a bug. It's one of the area in Blender that doesn't follow the philosophy of "don't think for the user". The depsgraph will decide in which order the modifiers should be applied and sometime fails at finding the right order, because in some case their are several possibilities, all valid and it's more a question of artistic decision.
The solution to it would be to have a way for the user to order modifier execution. The everything node system will solve it on the long term. In the meantime, it could be solved with a scene stack of modifiers instead of being limited to object stack.

The results are the same regardless of the Shrinkwrap modifier mode. The curve with the shrink wrap gets shrinkwrapped, but the objects that deforms along this curve doesn't follow its shrinkwrap deformation.

If you use project mode in Shrinkwrap modifier, I think that you have to appoint axis.

This should probably be merged with T50994 and T50819

I like the idea to add slider for the particles. It is quite usefull, when you want to give an offset for origin of the particle object to put it below/above emitter's face.

This is not a feature. Particles are simply ignoring the modifier options when doing the lattice computation. Disabling the lattice modifier should stop it from having any effect on anything on that object.

Particles deformed by lattice is a useful feature. Especially for emitter particles with physics, that allows to easily define flows for particles with erratic movements.

The error above somehow made me suspect if it is a problem related with the compiler used to build the program. So I tried the currently available latest x64 build (102394a).

No crash log appears to be generated. A "blender_a05604" temporary directory gets created, but it's empty. Nothing related in the parent temp directory or in the directory of the blend file gets created either.

Was crash log generated? Please upload if it does. Thanks.
https://docs.blender.org/manual/en/dev/troubleshooting/crash.html

No crash on OSX, same build.

Yeeahhh a big thank YOU Joshua !

There are currently location + rotation keyframes on some of the objects (frames 0 and 33). Try removing all keyframes before fixing the position of all the objects.

I have resolved the issue via a post at Blender Stack Exchange: To make precise dimensioning possible, one has to change the radius of the control points of the curve from 14 to 1!