Windows Update .mum format?

Your guesses about the <parent> element are probably correct. Assuming it is, I wouldn't consider the concept to be confusing or unusual, though. In order for the KB to be applicable to any given target system, the logical feature it updates must exist on said system. In the case of your KB2547666 example here, that's the Windows Search feature. The Windows Search feature itself is part of different larger logical feature groups on the various SKUs; e.g. it appears that Windows Search is part of the "WinEmb-Search" package on the embedded SKUs (not sure if in full or just in part), while "Microsoft-Windows-Client/Server-Features-Package" provides Windows Search for Server 2008 R2 (ditto). So, because any given logical feature can be provided by any one of multiple packages (depending on the SKU and which packages belong to that SKU), Microsoft simply lists in <parent> every package which provides that logical feature across all SKUs. This allows a single MSU file to be applicable to all SKUs, from client to embedded to server.

I'm not a Windows admin, and I might be using the wrong terms here versus any official vocabulary published by MS. This is just some speculation and intuition on my part. Hopefully this helps get the ball rolling on this thread.

 

Its a file format similar to .msu

 

I'm not sure about this. I don't know if these packages can logically contain each other, e.g. I don't know of any evidence that suggests WinEmb-Search is a hierarchical child of Microsoft-Windows-EmbeddedCore-Package. I would suspect they are distinct instead.

My speculation from my previous post was only that any given logical feature (like Windows Search) can exist in multiple logical packages.

This might just be a typical Microsoft (anti?)pattern in their use of XML during this era.

For .mums, it may be possible that, if there are multiple <parent> elements (with the same attributes (or lack thereof)), they are all concatenated together into a single effective <parent> element by the code that actually reads the .mum files.
For example,

Code:

...
    <parent>
     <assemblyIdentity buildType="release" language="neutral" name="Microsoft-Windows-InternetExplorer-Package" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" version="11.2.9412.0"/>
    </parent>
    <parent>
     <assemblyIdentity buildType="release" language="neutral" name="Microsoft-Windows-InternetExplorer-Package" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version="11.2.9412.0"/>
    </parent>
...

would be functionally identical to:

Code:

...
    <parent>
     <assemblyIdentity buildType="release" language="neutral" name="Microsoft-Windows-InternetExplorer-Package" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" version="11.2.9412.0"/>
     <assemblyIdentity buildType="release" language="neutral" name="Microsoft-Windows-InternetExplorer-Package" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version="11.2.9412.0"/>
    </parent>
...

I'm familiar with this Microsoft pattern from Visual Studio, where the xml project files typically have multiple <PropertyGroup> elements, all as siblings under the root element. When those <PropertyGroup>s have zero attributes, the project file is functionally identical if all the <PropertyGroup>s are consolidated into a single <PropertyGroup>. The primary intent here is actually to attach varying conditions and whatnot to each <PropertyGroup>, but when they all have zero attributes, multiple attribute-less <PropertyGroup>s can be used for cosmetic organization, which Microsoft deliberately makes use of in this case.

Spoiler: Cut-down .csproj example

Code:

  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <OutputType>WinExe</OutputType>
  </PropertyGroup>
  <PropertyGroup>
    <ApplicationManifest>app.manifest</ApplicationManifest>
  </PropertyGroup>
  <PropertyGroup>
    <ApplicationIcon>Icon.ico</ApplicationIcon>
  </PropertyGroup>
  <!-- This could just be one <PropertyGroup> and it would be functionally identical -->

Perhaps <parent> in .mums is the same way. In this case, there is a <parent> for x86 packages and a <parent> for x64 packages for the sake of cosmetic organization. Keeping the architectures separate helps humans avoid mistakes when handling these .mum files. And perhaps <parent> has some attributes which allow multiple sibling <parent> elements to be distinct, like in the VS example.

 

No clue, just speculation.

Consider a standard Windows version string:
6.1.7601.27265
which follows the standard Microsoft versioning scheme of Major.Minor.Build.Revision

Attribute buildCompare may be comparison to the build field, e.g. 7601.
Similarly, revisionCompare would then be comparison to the revision field, e.g. 27265.
Maybe versionCompare is comparison to the entire version string (all 4 fields), or maybe comparison to just Major.Minor (i.e. NT version like "6.1").
And serviceCompare sounds like service pack comparison, e.g. checking 7600 versus 7601 in this example.

All just speculation.