I actually don't think Minetest is, or will or should become, a voxel simulator in the sense you describe. In my conclusion I'll discuss what your idea is closer to, but first... Let's reason about what Minetest engine is actually made of for a bit. It's made of nodes, which are aligned on a 3D grid, and entities that have floating point coordinates on that grid
Nodes have complex, even intricate behaviour. There are elementary nodes like stone or cobblestone which have very little behaviour. Others have simple behaviours, like grass that spreads to dirt, gravel & sand that fall or water that spreads (engine feature). Finally we have nodes with complex behaviours, which often even store more information than what is 'native' to the engine, by adding node metadata or custom mod files - examples include a technic furnace or a mesecons FPGA. A lot of that final type have formspecs.
Also import to note about nodes is they come in many drawtypes - normal cubes, plant-like, rail-like, custom meshes and a few others. They are not, by the strictest definition, voxels. Voxels (volumetric pixels/volume elements) by a strict definition are all cubes. It is for this reason I can't in good faith call Infiniminer-Minecraft derivatives voxel games. I call them Blocky - others sometimes say Block - games.
Entities are different and act as complex agents in the world. Even in a pure voxel engine they might remain unchanged.
Most games on the engine take after Minetest Game and have a lot of formspecs. Only a few, like Nodecore, don't follow this pattern. If nodecore-like games based on physical and direct properties of nodes, and arrangements of nodes, were all that we wanted to make on Minetest Engine, then I might even agree that we should develop the engine to improve performance around simulating them. We would write highly efficient realistic water spreading, cheaper falling sand. Like others have discussed we might add more layers to the world than just the nodes - thermodynamic temperature, presence or absence of air, even humidity. I won't go into them in depth, some people have discussed them ad nauseam elsewhere in these forums.
As Mantar mentioned MTG will remain MTG and successors will or won't be forked from it, but MTG will be itself still.
The problem I see with going in the physics simulator direction is a sharp break from where the engine's games are at. There's no point adding features people simply won't use in their game. For example if nodes had temperature, there'd be temperature in Minetest Game all of a sudden, even though it's never had a conception of temperature before. When it comes to these features from a Minetest Game point-of-view - at best if they can all be turned off, it's an anti-lag feature to revert back to old behaviour. At worst, it breaks compatibility. The middle ground is wasted computation and wasted time configuring around things.
So back to my conclusion: No, Minetest Engine won't become the voxel physics simulator. But! That doesn't mean such a simulator couldn't exist or wouldn't make sense. It would be more like powder game (the original is
here). The original powder game was a great toy, a great game. The first I know of in its genre, and it inspired derivatives in Powder Toy and later Noita. Probably others I don't know about. Taking the genre 3D presents unique challenges; I'm reaching the edge of my knowledge for sure here! Has someone tried that? Nevertheless, I hope you can see how different the pixel/voxel physics simulation genre is from Minetest, and why it should be a different game engine. There are quite simply different considerations to be built into different types of games and their engines.
Further reading: further games that are fundamentally not Blocky games, but are highly sandbox-like like Infini-Minecr-test:
- Space Engineers & Medieval Engineers - featuring voxel terrain
- Valheim - featuring heightmap terrain
- Universe sandbox
