Fundamentally, it’s not always possible to combine all possible modifications.
You run into the “unstoppable force, meet immovable object” problem – one must win!
If you define the API for your objects from scratch, you can use patterns that make this less problematic.
For example, you can use delegation instead of inheritance – the function to “set player velocity” or whatever, is actually a function (or method on an extension object) that takes a pointer to the base player, and a reference to the velocity to set, rather than just a method on the player. That way, you can call each mod override in turn, without having to make up an explicit inheritance chain.
As another example, you can broadcast upadtes to world state using a de-coupled event bus, where extensions listen for events of particular shapes (type, sender/receiver filters, location filter, etc.) That way, many extensions can listen for the same changes.
Of course, these changes may be hard to implement in a system that already has a strong opinion on how objects go together. And, even when you implement them, they have more runtime overhead: performance cost, memory cost, also implementation having to worry about which places are extension points. “Good moddability/extensions” is a feature, and every feature has a cost, so the trick is to achieve the right balance between “feature” and “cost” for what your needs/goals are. This is why we call it “engineering” 