I don't know if all of these could be solved with on_step callbacks, but I agree this could be useful. An example would be having liquid flow or conveyor belts move items around.

Having an on_step may be costly. How about an event for when the entity is created, and when it is destroyed?

The '__builtin:item' does have already an on_step function to handle falling and item merging. I search for a way to enhance them for other physics. on create and on destroy are maybe usefull to, but not enough.
An other way could be something like
minetest.override_entity('__builtin:item', on_step = new_on_step)

Adding another callback is not really a solution.
What if more than one mod wants to add its own things to handle inside the on_step?

You'll have the same problem, you'll have to override this new callback, and to make sure you don't conflict you should call the old callback inside your own callback.

At the moment there's no register_step for entities (analog to register_globalstep).
Until there's such thing overriding makes more sense than adding a new callback for mods to fight for, imho. Just make sure you do call the original on_step within the new on_step.
That way mods can stack up features without having to add special logic in builtin that has to check for callbacks in every step.

What if more than one mod wants to add its own things to handle inside the on_step?

Primary I search for any way to change the builtin behaviour. Usually it is enoug to redefine the functionality once in subgame. If multiple mods needs to redefine the behaviour, it is possible to create an "on_step = local old_onstep + new_onstep" wrapper chain, like sometimes seen for node's on_use. If really a lot of mods requires them, an builtin_item_manager mod can be written that redefines once the builtin's on_step and the provides the register_item_entity_on_step() function or something like.

New idea is to do it like the minetest_game abm for lava-cooling

core.builtin_item_on_step = function( ...
--
end

register entity(..
on step(...)
    return core.builtin_item_on_step(...)
end

This way it is possible just to replace the core.builtin_item_on_step in other mods

But I prefer the minetest.override_entity() for now (like exitsitng minetest.override_item()) because of the most flexibility

👎

You should use override entity and wrap around the old on step

But I prefer the minetest.override_entity() for now (like exitsitng minetest.override_item()) because of the most flexibility

Should I adjust the initial post to request the minetest.override_entity()?

You can already override the entity using minetest.registered_entities, but an override_entity method would be nice

I do not know how the table content minetest.registered_entities is synchronized to the engine, therefore I access such tables read only. To change builtin things an method should exists.

I know the way to get the full definition from minetest.registered_entities, modify the method and then re-register using core.register_entity(":__builtin:item" modified_def), but I do not like this way

This should work:

local builtin_item = minetest.registered_entities["__builtin:item"]
local item = {
    on_step = function(self, dtime)
        builtin_item.on_step(self, dtime)
        -- do your stuff
    end,
    --- additional stuff if needed
}
setmetatable(item, builtin_item)
minetest.register_entity(":__builtin:item", item)

You don't have to directly write into minetest.registered_entities (although you can), the right way would be to use minetest.register_entity to override it, prefixing the name with a ":".

Entities aren't synced to the engine at all, the engine reads the table. The only reason that items are synced with the engine is so they can be sent to clients - entities have object properties binstead