It is a built-in to the language allowing an object with the right methods to masquerade as a native data structure. To get the object with the right methods you would write a module, but the tie itself is not implemented as a module. People get all worked up about this, but it is really a simple concept. The one that you're thinking of would be written like this (untested):

\n  package Tie::Original::Keys;\n  use strict;\n\n  sub TIEHASH {\n    my $class = shift;\n    my $self = bless {\n      hash => {},\n      original_key => {},\n    };\n    while (@_) {\n      $self->STORE(splice @_, 0, 2);\n    }\n    return $self;\n  }\n\n  sub FETCH {\n    my $self = shift;\n    my $key = shift;\n    return $self->{hash}{$key};\n  }\n\n  sub STORE {\n    my $self = shift;\n    my $key = shift;\n    my $value = shift;\n    $self->{hash}{$key} = $value;\n    $self->{original_key}{$key} = $key;\n  }\n\n  sub DELETE {\n    my $self = shift;\n    my $key = shift;\n    delete $self->{hash}{$key};\n    delete $self->{original_key}{$key};\n  }\n\n  sub CLEAR {\n    my $self = shift;\n    $self->{hash} = {};\n    $self->{original_key} = {};\n  }\n\n  sub EXISTS {\n    my $self = shift;\n    my $key = shift;\n    return exists $self->{hash}{$key};\n  }\n\n  sub FIRSTKEY {\n    my $self = shift;\n    # reset each() iterator\n    my $a = keys %{$self->{hash}};\n    return each %{$self->{hash}};\n  }\n\n  sub NEXTKEY {\n    my $self = shift;\n    return each %{$self->{hash}};\n  }\n\n  sub SCALAR {\n    my $self = shift;\n    return scalar %{$self->{hash}};\n  }\n\n  1;\n

after you've done all of that you can write things like:

\n  tie my %is_seen, 'Tie::Original::Keys';\n  $is_seen{$_} = 1 for @non_unique;\n  my @unique = keys %is_seen;\n

and the stringification issue that I named is gone.

That's well, fine and dandy. But there are a host of problems with it.

1. Using tie has a huge performance overhead. Here is a much faster solution to the above problem:
   

   \n  my %original_key;\n  $original_key{$_} = $_ for @non_unique;\n  my @unique = values %original_key;\n

   
   So you see that the technical note about keys is just that, a technical note. Sometimes you need to know it, but if it matters to you, it is easily worked around.
   
2. Using tie is horribly confusing to people. That is because the language sets up strong expectations that native data structures really are native data structures, and now you violate those expectations. Without those expectations it would be a very simple idea, with those expectations there is considerable surprise.
   
3. Historically tie has been a bit buggy. A fair fraction of the bugs that I know of in Perl involve tie in one way or another. That is because of the implementation, where every internal function in the API checks for whether a data structure has "magic" associated with it, and if it does it does something based on that magic. So the implementation is scattered throughout procedural code. And there are bugs. (It should work pretty well now though.)
   

Now one personal note. Many people seem to think that tie is somehow "very cool" and is a sign of really interesting stuff being exposed from within Perl. It isn't.

Tie is a band-aid for a self-inflicted wound.

Perl goes through a lot of work to make a specific set of data structures available to you. It is a well-chosen set; it is surprisingly hard to find an algorithm in which the naive implementation in Perl using those data structures (particularly hashes where they make sense) is not the same as the sophisticated algorithm. (Different constants though.) However sometimes they are not what you need. When they are not, then you have to rewrite a lot of code to be able to get custom data structures (aka objects) that do exactly what you want to. Or else you can use tie and avoid a lot of the rewriting.

For an example of how to solve the same problem by not creating it in the first place, see Ruby. Everything is an object. The objects for native data types are accessed in the same way that your user objects are. If you want something that is the same as a native data type only slightly different, you can just write your own object for it. If you want something that is the same as a native data type but has extra capabilities that is also easy - just have a new method. (In Perl you wind up having to write crap like tied(%foo)->some_method_call(); Ugh.)

Now you can object that a native data type has a lot of behaviour. Implementing all of that is hard. Sure you could, but would you in practice?

Well it turns out that you only have to do the heavy lifting once. Ruby supports mixins, that make it possible to support a complex API from a simple one. So you can exactly parallel what Perl does. You implement several base methods, mixin the right class, and now you support the full API of a native datatype. Only it doesn't look like magic when you do it, because the idea fits into the language as a whole rather than being a hacked-on piece of "magic".

Cheers,
Ben