This issue is not new, but since some latest Microsoft D365 updates which have introduced new models in the standard application, I've seen a lot of people asking for help. 

The problem that people are facing is following: When installing a deployable package - may it contain Microsoft updates, ISV solution or your customizations - the installation fails with error that says there's already another model in the target environment, having same id than one of the models in your deployable package.

The reason for the problem is that model ids are not globally unique. Also Microsoft models, ISV models and customization models are getting ids from the same space, increasing the likelihood of conflicts. According to Microsoft, they can't resolve this characteristics easily, so we have to concentrate on mitigating the consequences.

Where does the model id come from?

The model id is created when the model is created, either in Visual Studio or by importing a model from .axmodel file. If a model is imported over existing model with -replace switch, the model id in the system doesn't change. If the old model is uninstalled before importing a new version, the model id will change.

The model id stays with the model when it's built into a deployable package.

Why are there conflicts?

When importing or creating a model in a development system, the new id will never conflict with any existing model in the system. However if a new deployable package is installed in the system (Microsoft update or ISV binaries), that package can contain conflicting model ids. Also, installing deployable packages in a Sandbox or Prod system might lead to conflicts. But assuming you don't have any models / packages in your Production system that you don't have in your Sandbox system, you should never encounter model id conflict during Production deployment. Instead you catch the issues latest in Sandbox deployment and can fix them.

How to fix the conflict?

As mentioned earlier, the model id is defined when the model is created, or deleted and re-created. This means that you can solve the issue by removing and recreating your conflicting model in a development system, and building a new deployable package from your source code. However it can be that the id conflict comes from an ISV model, and they have given you only the binaries, not the models. In this case you will have to ask your ISV to recreate the model and send you a new deployable package. If the conflict is between two ISV solutions, one of them has to change their ids. It's definetely not a nice situation for ISVs who have many customers who might have many ISV solutions. But so far this is the only supported resolution.

How to NOT fix the conflict?

Any other way than reinstalling the conflicting model is not supported by Microsoft. You should not try to tamper with ISV (or Microsoft!) binaries.