I'm going to explain my question with a concrete example where this question has cropped up:
I'm working on a large-ish Django project with a few people. Django automatically creates migration plans and saves them to separate files when the database model is changed. Edits to the model may be applied on different branches in parallel. Django actually supports this with the introduction of merge migrations.
In essence, after merging branches with diverging changes to the model, you create another migration plan which references all the leaves in the graph of migration plans (comparable to the way Git represents merges).
Now my question is this: On the grounds that after merging branches without adding the merge migration, the project is not broken per se (an existing setup continues to run), but its also not in a very good state either (you can't apply migrations to a database or initialize a new one), should I include the merge migration in the merge commit itself or should I add it in a separate commit? What are the implication of doing it in one or the other way?
My question is about the general case where a merge introduces inconsistencies, not by breaking the code itself (i.e. renaming a method where another usage has been introduced in the other branch), but on a higher level, which could include inconsistent documentation or broken auxiliary data (test data and scripts, installation scripts, default settings files).