I have the same “problem” and I resolve in the same way as you do.

Could we even simply ignore the .nch file in our git repository?

I don’t think so, because you would lose track to old cases (AIMMS .data files).

A similar issue has been discussed here before regarding merging of .json files. The solution for that was to sort entities in the webui.json file alphabetically.

So I am wondering if the same approach would work for .nch files?

The .nch file is used in several parts of AIMMS:

1. Indeed: for cases. The most relevant now-a-days where most applications are WebUI based. Via the .nch file AIMMS knows how to map old names that are stored in a case onto the new names in the model.
2. In the WinUI, for all references to identifiers stored in pages and user menus.
3. Sometimes for libraries, which were readonly at the time the name change was done.

The best advice for handling the .nch file when multiple developers are working on the same model is:

• Before committing: do a ‘commit namechanges’ in your model. This assures that WinUI and all (non-readonly) libraries are up-to-date with the latest namechanges. 
• Check whether new entries in the name change file are relevant for any cases that may exist at the users of your model. For example, if the name changes only refer to newly created identifiers they are kind of redundant after the ‘commit namechanges’ command.
• If you have a conflict: try to preserve the time stamp order.

Regarding the order of entries in the .nch file: 

For AIMMS the time stamps are relevant, and that is why these are used to order the .nch file. You can now read the .nch from top to bottom to see how identifiers have been renamed over time. Changing this only because of source control benefits does not seem the right thing to do.

If you use Git, then you can use the .gitattributes file to set the merge strategy to union. This basically automates the manual step you're currently doing (mine before theirs). The contents of the .gitattribute file should be: 

*.nch merge=union