I'm not quite sure how I feel about making this engine responsibility. Games need not have a concept of "default physics" at all. I think usually physics overrides are best managed as "monoids": All operations performed upon them must be invertible and associative. This is implemented by mods such as this one.

When you have something like minigames where you change physics, I would recommend saving the previous physics (from before entering the minigame) and simply restoring these at exit.

I don't think a mod dependency is a big problem. Mods will have to depend on fundamental game mods for fundamental game features (such as this one) anyways. Though now with the addition of the first_mod feature, you could even have a mod load first in a game without other mods needing to depend on it.

I also don't think moving this inside the Minetest namespace helps much with conflicts: You can still have multiple mods trying to set these defaults and hence conflicting.

There are default physics values, hence there is a default physics. I've seen the monoid mods but frankly I find it confusing. Also, there are a lot of them

You can still have multiple mods trying to set these defaults and hence conflicting

Sure but at least I have a starting point. Mods cannot know what's a server default physics, and this parameter would help because the server could state so. Of course speed potions etc shouldn't touch such a parameter

some mods can tweak it

One way to change the defaults currently is with the movement_ settings although not sure if setting at runtime works. The physics overrides are relative to these settings