Volume distribution of particles is currently quite a mess, and the issues go far beyond voxel textures, it actually often fails even just with a mesh.
Particles and caching are subject to an overhaul in 2.8, so we are limiting the work on the current system to only regressions.
Thanks for the report, but as this is not a regression, archiving it for now.

Hm, seems the issues here go much further than described. Besides not generating consistent amounts of fluid, the animated version causes the fluid to have a gigantic cavity, essentially turning it into a hollow "shell" of fluid.
From a quick look at the code I didn't get to any conclusion, but then again, I'm not familiar with the Elbeem code at all. This will require some more digging.

Can confirm. With new DEG, bone motion freezes when changing the IK length, and second attempt at moving causes crash.

Confirmed. Something in nlastrip_evaluate_controls is causing this.

Seems in your area @Bastien Montagne (mont29).

Just saw this revision now, didn't catch the notification for this :|
This looks fine. Just note that the same should be done for the opposite case... Setting the end frame lower than the start frame should also lower it.

Oops, forgot to mark the task in the commit...
This was done in d04f30c5d84889b9c4c77e102726c6d595518984

This was before particles were being handled in the draw manager. Drawing code has been rewritten, and this should not happen anymore.

Nope, I tested with CoW disabled... So this commit has some kind of side effect.
I thought it was odd as well, but for some reason it works.
(idk, might be as silly as some new include adding some #define that was missing, or something like that... for instance, I remember we had a missing preprocessor directive when particles were brought back...)

This has been solved by 802027f3f8f9a83a77134a2b104a25ff3a4ac013

This has been solved by 802027f3f8f9a83a77134a2b104a25ff3a4ac013

Resolved by rBaaf37e1216b2a9dfc43591e227c679a5b35af8c0

Particle drawing has been implemented for object mode, and hair has been implemented for Clay and for Eevee.

Thanks for the report, but this is not a bug. The tangent is calculated in relation to the face's UV orientation.
Without having your mesh unwrapped, you will effectively have random tangent directions.
To have proper tangents, you should unwrap your mesh, and orient the faces on the UV map in such a way that the tangents point to where you desire. (Note that the tangents run along the UV Y axis)

Thanks for the report, however, this is not a bug. The faces being bridged are intentionally removed, to avoid the occurrence of internal faces, which are generally undesirable.

This happens whenever you try to scale an object along a non-local axis aligned direction. This is due to Blender not supporting skewing of objects.
The scaling along each local axis will be proportional to how much it contributes as a component of the axis your are scaling on.
Thanks for the report, but this is not a bug.

This is not really a bug, but rather a known limitation of Blender's UV mapping algorithm.
Unfortunately there is not much we can do about this, short of rewriting the whole UV mapping system.
You can however minimize the issue by subdividing your mesh a few times.

This is an odd behavior indeed. Might be a mesh evaluation order issue...
However particles are subject to an overhaul in 2.8, so we are limiting the work on the current system to only regressions.
Thanks for the report, but as this is not a regression, archiving it for now.

Regardless of recalculating on every frame or not, this is undesirable behavior and should not happen with a proper interpolation system.
However, particles and caching are subject to an overhaul in 2.8, so we are limiting the work on the current system to only regressions.
Thanks for the report, but as this is not a regression, archiving it for now.

Particles and caching are subject to an overhaul in 2.8, so we are limiting the work on the current system to only regressions.
Thanks for the report, but as this is not a regression, archiving it for now.

This is still WIP.
The difference at this point is only the format of the size attribute which I changed in 6f063bdb1c316d31d108d2d609de36a0e4461db5.
But in a few minutes I'll be pushing more changes, which for instance add support for drawing velocity and acceleration data as colors in the shader.