Ok. The claim that git is inconsistent is wrong. From OP:

The problem with git’s merging is that it doesn’t satisfy the “merge associativity law” which states that merging change A into a branch followed by merging change B into the branch gives the same results as merging both changes in together in one merge.

There is no such concept in git as "merging both changes in together in one merge".

I have modified a shell script written by Simon Marlow that illustrates, using git, how merging two patches separately can give different results than merging two patches together.

The shell script doesn't do what is claimed. It can't because git has no facility for "merging two patches together". Git can only do 2 things with patches:

1. generate a patch

2. apply a patch

But! git has a function which is equivalent to combining 2 patches in a single merge:

git pull --rebase

The shell script does not use this command. It first applies 2 patches separately. It then applies 1 patch separately.

There are still some people who still think nothing is wrong with git; that it is okay for the result of a merge to depend on how things are merged rather than on only what is merged; that is it okay for two git repositories that pull the same patches to have different contents depending on how they pulled those patches. I don’t know what to say to those people.

This is just incoherent. I have no idea what to say in response because I have no idea what the intended meaning is.