I wrote and released a Windows application that specifically solves the problem of comparing and merging XML files.

Project: Merge can perform two and three way comparisons and merges of any XML file (where two of the files are considered to be independent revisions of a common base file). You can instruct it to identify elements within the input files by attribute values, or the content of child elements, among other things.

It is fully controllable via the command line and can also generate text reports containing the differences between the files.

Focusing on the part that moved sections should be reported as no difference made me think of https://semanticmerge.com/, which doesn't compare XML-files, but C# and C code. And as it understand those languages it is able to display if code has moved and not changed.

This leads to an alternative approach for this question: Could it be possible to translate the XML into C# classes, and then do a semantic merge on the resulting code?

One possible approach, if this tool is not written already, could be to translate each and every element to classes, and each attribute (and body texts) to a string property within that class. If you want to ignore namespaces, then let your translator remove them in the translation process.

I translated the XML example given as proof of concept and got the following:

class soapenv__Body {
  class mes__GetItem {
    class mes__ItemShape {
      class typ__BaseShape {
          string body="IdOnly";
      }
      class typ__BodyType {
          string body="Textus";
      }
      class typ__AdditionalProperties {
        class typ__FieldURI  {
            string FieldURI="item:Subject";
        }
        class typ__FieldURI  {
            string FieldURI="item:Categories"; 
        }
      }
    }
    class mes__ItemIds {
      class typ__ItemId {
          string Id="AAMYAAA=";
      }
    }
  }
}

Then I switched the mes:ItemIds and mes:ItemShape and changed the text to Textus. Compared the following two files in Semantic Merge and got the following image:

In this image one can see the move, indicated by the M icon, and the change in text indicated by the C icon. Lines indicates where the different parts have moved/changed, and it possible to actually see the differences if they exist.

Note that Semantic Merge even though understanding C# code, isn't to strict on the identical class names of typ__FieldURI, which could be a nice features as XML can contain multiple nodes with the same name.

Summa summarum: Semantic Merge can correctly identify the XML as identical (or not) even though elements move, if you can convert the XML into a C# class structure.

That's quite a challenge, because so many differences are possible: you may have to make compromises depending on what you actually encounter. (For example, you may or may not need to bother with named model groups, depending on whether either of the schemas you are comparing actually uses them. Most schemas don't.)

If I were doing this (and of course I'm biased towards using my own tools) I would start by using Saxon's schema validator to generate SCM (schema component model) files for both schemas. This will do a fair bit of normalization, e.g. handling the difference between inline types and references to named global types. I would then write an XSLT stylesheet to do further normalization on the SCM files, for example sorting components into a canonical order, sorting enumeration values, and so on; also, eliminating the parts of the SCM files that aren't relevant, such as finite state machine details. I would then probably write a custom XSLT comparison module to compare the two normalized SCM files (along the lines of https://dvcs.w3.org/hg/xslt30-test/file/tip/runner/compare.xsl which is used for comparing XSLT test results) - the key being that you don't just want a boolean answer saying whether they are the same or different, you want to highlight the differences. Alternatively you could use fn:deep-equal to test whether they are the same, and then using a visual diff tool to examine them side-by-side if not.