Basically, H2I returns a unique integer for each handle (a handle is an object class, of which all other objects, except string real int and code are sub-classes). This integer refers to the slot in the handle index (basically that integer relates to the slot that the variable, which is a pointer, points at).
Local Handle Variables convert that integer to a string, and then uses the game cache to attach to the handle slot that the handle is occupying. Note if the handle is destroyed, the slot may be reused and then, if not defensively programmed, data can be transferred incorrectly from one object to another (this doesn't occur with variables, which keep a reference and so switch to null when the object is destroyed).
Where did you get that idea? Did you get it from Vex? I need proof before I actually trust something (most of the time).
We've got working examples of the handle stack being corrupted, for example (eg: in cases of handle objects. Any system based on handle slots instantly go boom. Any handle variables may get screwed by that, but those attaching ints/reals/strings suffer less from it, and are less likely to screw up from what I gather.
I'm a bit hazy on the exact details, and it's late, so take everything in the last paragraph with a pinch of salt, and go speak to Vex or PipeDream or someone if you want the details.
EDIT:
The 'myUnit' part is any handle variable, such as a unit variable, eg: udg_Unit.