This might not be the right place to discuss. However, I don't really understand this:
If you have added a texture to a particle (hair) system, and you hit 'Bake', you get an 'empty bake', that is a simulation doing nothing. Ignoring all fields you have added. Without any warning or notice, that you have to remove the texture again before you can get a usable result. To be more clear, you get an 'erroneous result' without any hint why. This is considered a limitation?

Yes. It is an already reported problem. Not really a bug but a known limitation.

Is it fixable in future blender releases?

Perhaps this is related to a couple of the "archived" bug reports?

Thank you Brecht! This being my first blender patch, I feel very proud :-)
Cheers

Finally someone noticed! ^_^

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.

Yeah, there is a weird difference between animated and non-animated inflow mesh here, not sure why… Maybe our emeritus physicist @Luca Rood (LucaRood) wants to have a look? ;)

Claiming the task is fine, patch committed now.

It is happening for us all the time, in more than 10 frames out of 180 of a simulation (resolution 550, smoothing 1, remove air bubbles Yes, speed 0.8).

Okay, here is what happened:

1. The "crash" occurred only in Debug build configuration.
2. When reading particle velocities from disk, the number of particles from the file header were not considered. They were only set in the particle system (positions, flags) reading routine. It's apparently safer to read them twice.

Here is the patch:
https://developer.blender.org/D2719

Sorry it's my first bug fixing time, i'm not sure to do it right.
I have a patch for this, can I claim this task?

Yeah, I'm on it. Just couldn't reproduce the "instant crash" on neither Linux nor OSX. So it's either really a Windows problem or a faulty build.

Ideally would be better to communicate directly with the branch's author in that kind of cases… Will let @Sebastián Barschkis (sebbas) decide now.

In the fluid domain settings, there's different Final Display and Viewport Display modes. If those match the result is the same.

OK: I've finally found some time to write some better documentation for this, but it'd be useful to check if this is correct. It seems:

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.

Confirmed, issue is in DM evaluation code actually, never clears the deformedOnly flag when evaluating a generative modifier!!!

Very nice solution, Aaron! ❤

Here is a fix which uses a soft limit of 50 and a hard limit of 128:

I have observed the same bug. I guess it sill hasn't been addressed?

All I want to achieve is to fluid inflow object emit fluid the same way on animated mesh as on non animated mesh. I already tried the displacement and ocean modifier, looks good but I wanted drops dripping from running character. As soon as I tick option "export animated mesh" inflow emits enormous amounts of fluid. Is there a way to make deformed mesh emit fluid like non deformed (not animated)?

Thought: perhaps renaming it to Boid Goal/Avoid field would help.

Crikey, just had a quick play—thanks Ronan!—and this is a hugely valuable feature. As he says, it lets you animate between Goals rather than moving the Goals (which produces a different effect). The lack of docs is the killer—the fact the strength needs to be negative for Goal use means it's even more unlikely folks will just stumble across its functionality.