Data-Driven Minecraft Should Give Us Systems, Not Checkboxes

I’ve followed Minecraft’s move toward data-driven systems for a while, and 26.4 Snapshot 3 finally made clear what has been bothering me: we’re often getting checkboxes, not systems.

Tags like #spawns_strays_without_powder_snow, #melts_icicle_above, #frostbite_preferred_weapons, and especially #knocks_back_players_even_with_zero_damage technically move decisions into data, but don’t make the underlying mechanics data-driven. They expose specific exceptions to hardcoded behavior.

Instead, datapacks need composable primitives. Damage and knockback could be independent effects. Mob equipment preferences could be generic behavior. Spawn conditions could be composed from predicates. Environmental interactions could use reusable properties/effects. Vanilla features should then be built from these same systems.

A good test should be: can Mojang implement most of a new game drop using the data-driven systems already exposed to datapacks, without adding feature-specific game code?

When a new feature requires engine work, ideally that work adds a general primitive which both Mojang and datapack authors can use. Vanilla development would then dogfood the datapack API and naturally expose missing abstractions.

It feels like data-driven is measured by what moves into JSON, not what new behavior it enables.

Moving an if statement’s exception list into a tag is useful configuration, but it isn’t the same as making the system data-driven.

Please give datapack developers systems, not checkboxes.