The bug

Water and lava are capable of producing minecraft:block particles of themselves in certain situations.

The fact that particles can be produced at all makes no sense, as there are several other blocks in the game for which particles are never produced since particles being produced for them also makes no sense.

Table of results

The following table lists all cases in which minecraft:block particles are generated, and water and lava's behaviour for each of these cases. The expected behaviour for all of these is that no particles are produced.

Event	Result	Notes
Process of breaking	N/A	Water and lava cannot be targeted, so this is impossible
Being broken	No particles	Only possible with commands: /setblock ~ ~ ~ air destroy
Being sprinted on	No particles	Previously the case, fixed in 1.13
Being fallen on	Particles created	Must be reproduce through MC-207949
Being walked on by an iron golem	Particles created
Being dug through by an emerging warden	Untested
Being dug through by a departing warden	Untested
Being dug through by a sniffer	Untested
/particle command	Particles created	Example: /particle minecraft:block minecraft:water

Expected behaviour

As mentioned before, block particles for water and lava should never be created, even if summoned with commands. Currently, only the following four blocks will never show block particles, behaviour which water and lava would be expected to follow:

• minecraft:air
• minecraft:cave_air
• minecraft:void_air
• minecraft:moving_piston

Actual behaviour

The game does indeed prevent water and lava block particles from being produced in some cases. However, there do still remain cases where block particles are created, which can be seen in the table.

How to fix

Removing the particle texture definition from the models would not fix this issue, as the game would simply fall back to using the missing texture. As such, fixing this would require code changes. A simple fix would be to just hardcode water and lava to not use particles just like the four aforementioned blocks, but a more data-driven solution may be preferable, removing this hardcoded list from the game.

• A new top-level parameter could be added to the top of model files, similar to "ambientocclusion", called something along the lines of "allow_particles". True by default, it could be set to false for specific models to prevent particles from ever being created for it. The models for the three air types as well as moving pistons would be modified to include this parameter, setting it to false. This would allow for easy customization of what blocks (or, more specifically, models, extending this to items) do and do not have particles using resource packs.
• A block tag could be added (possibly named #minecraft:no_block_particles), the members of which do not display block particles under any circumstances. This would include the four block IDs mentioned above, as well as water and lava to fix this report. This would allow for data packs to be used to customize what blocks do and do not use particles by ID.
• Instead of a single block tag, there could instead be multiple block tags for specific cases of particle generation - for blocks, a dedicated tag each for the process of breaking, fully breaking, sprinting, falling, iron golem walking and some sort of "master tag" for summoning via commands. Individual customizability could allow for fixing things like MC-167886, so that nether portals can show particles when broken but not when punched. This could extend to other particles such as block_marker, with a tag for when held and a dedicated master tag for it as well, which could fix MC-239407 if air variants specifically are blocked from showing block_marker particles but barriers and light blocks still would be able to show particles, and item, with tags for players eating, foxes eating, pandas eating, tools/armor breaking and a master tag for it, which could also blacklist air to fix MC-122177.
• An analogous approach that allows for particle types to be in models per "emission circumstance" would likely be very complicated and make things needlessly difficult for mods and their compatibility.