=== Idea of refactoring Key PMC ===

Current Keys are messy and incomprehensible. So there is idea of refactoring them into something more sane.

Keys currently serve only one purpose: navigate in nested containers. Iteration over containers was removed as part of key_revamp branch.
To support this functionality more implicit and in clean way we will:

1. Add {{{KeyItem}}} interface class to represent single abstract step.

2. Implement {{{StringKeyItem}}}, {{{IntegerKeyItem}}}, {{{PMCKeyItem}}} and {{{RegisterKeyItem}}} to store concrete value for each step.
Such {{{FooKeyItem}}} will implement {{{get_foo}}} vtable methods, freeze/thaw and nothing else. We don't need FloatKeyItem because float keys are meaningless.
{{{RegisterKeyItem}}} will store tuple {{{register_type, register_number}}} to reference particular register.

3. {{{FooKeyItem}}} will not be directly constructable by throwing exceptions from {{{init}}} and {{{init_pmc}}}

4. {{{RegisterKeyItem}}} will be directly constructable and implement {{{set_integer_keyed_int}}} method to set {{{register_type}}} and {{{register_number}}}. 

5. Re-implement Key as:

  a. RPA for storing *KeyItem.

  b. Various {{{push_foo}}} vtables to create specific FooKeyItem and append it to path.


=== Pros ===

1. Keys PMC become almost equal to all other PMC in terms of handling (especially in PBCs).

2. Each {{{FooKeyItem}}} will have clean set of responsibilities.

3. It will speed-up keys handling slightly because we'll avoid big switch statements in each Key.foo vtable methods.

4. Run-time creation of keys will be simplified to something like

{{{
  # We are creating [42;"foo";84;"baz"] key.
  $P0 = new ['Key']
  push $P0, 42
  push $P0, "foo"
  push $P0, 84
  push $P0, "baz"
}}}

5. Making mistake in Keys creating/using will be almost impossible.

=== Cons ===

Someone will have to patch IMCC to support new Keys.