Mind explaining the ==/=== issue which arises from the high/lo and array solution?

As parent mentions, comparison with ==/=== are "broken" for arrays or classes. Or more accurately, they now do reference comparisons instead of value comparisons. This means you have to replace a lot of this (using Flash/ActionScript as the example here):

  function updateIcon(id: int, ...) {
    for (var icon in icons) {
      if (icon.id === id) {
        ...
      }
    }
  }

With, say, something like this:

  function updateIcon(id: Ptr, ...) {
    for (var icon in icons) {
      if (Ptr.compare(icon.id, id) === 0) {
        ...
      }
    }
  }

Or:

  function updateIcon(id: Array, ...) {
    for (var icon in icons) {
      if (ObjectUtil.compare(icon.id, id) === 0) {
        ...
      }
    }
  }

Assuming you want to preserve the exact semantics of the existing code. If you miss a single comparison, your code will still compile. You will get no runtime exceptions, because == and === are still legal. It'll just have a subtle runtime flaw that will only manifest itself if two interop sites construct the same pointer value as different Ptr or array instances without interning (read: caching/leaking Ptr or array instances, which has it's own problems.) You cannot override == or === to do the right thing (tm) either.

In the unlikely event you do a large refactoring or conversion completely flawlessly, your coworker's muscle memory will, rather understandably, still end up causing problems.

  function updateIcon(id: String, ...) {
    for (var icon in icons) {
      if (icon.id === id) {
        ...
      }
    }
  }

This is less refactoring, and just works(tm), because String ==/=== already compares the value of the strings. No muscle memory to update, easier to print in debug and trace statements, etc...