// Objects major update: we will update to the first minor of the next major version - we can not skip major versions or jump directly to a higher minor of the next major version.
  if (rUpdateVersion.iVer[2] > C4XVER3)
    strUpdateURL.Format(Config.General.UpdateMajor, (int)rUpdateVersion.iVer[0], (int)rUpdateVersion.iVer[1], C4XVER3 + 1, 0, C4_OS);
  // Objects version match: engine update only
  else if ((rUpdateVersion.iVer[2] == C4XVER3) && (rUpdateVersion.iVer[3] == C4XVER4))
    strUpdateURL.Format(Config.General.UpdateEngine, (int)rUpdateVersion.iBuild, C4_OS);
  // Objects version mismatch: full objects update
   else
    strUpdateURL.Format(Config.General.UpdateObjects, (int)rUpdateVersion.iVer[0], (int)rUpdateVersion.iVer[1], (int)rUpdateVersion.iVer[2], (int)rUpdateVersion.iVer[3], (int)rUpdateVersion.iBuild, C4_OS);

I think the three URLs are due to an optimization regarding the engine. The engine is always included in full, and thus "cumulative" to all older engine versions. But cumulative object updates grow bigger the more older versions have to be supported, so every few versions a cutoff is made: The update to x.0 applies to all (x-1).y, and updates to x.y1 apply to all x.y0 where 0<y0<y1. Example:
1.0 [71]
1.1 [72]
1.1 [73]
2.0 [74]
2.0 [75]

So if you have 71, you can update to 72 and 73 with an "object" update, to 74 with a major update, and not to 75.
If you have 72, you can update to 73 with an engine update, to 74 with a major update, and not to 75.
If you have 73, you can update to 74 with a major update.
If you have 74, you can update to 75 with an engine update.

So I'm not sure whether we should keep this scheme: The engine update optimization depends on engine updates being more frequent than object updates, but this isn't the case with OC at the moment, and I think that's a good thing. We might even want to look into pure object updates, which can be a lot smaller.
Generally, this is all a tradeoff between the number of update packages a player has to download, the download size, the number of update packages we have to produce, and the number of old versions we have to keep around. We could optimize for the first two by providing optimal update packages for every combination of old and new versions, or for the last two by providing only updates from one version to the immediately next one. But that has an additional downside: In case we produce a broken update, we can't supersede it by providing a cumulative fixed one that allows players to skip the broken one. So some form of cumulative updates should be provided.
I think we might want to move the "which update package to download" logic into the masterserver. That way, we can decide at update creation time how the packages should look like, and not when producing the old version.