I have run across a situation where I need a Switch statement.

That need is of your own creation. There is no situation where the lack of a switch statement will prohibit the project from moving forward with efficiency and clarity. Perl5 was a dozen years old before it got a switch statement (called given/when), and the addition of that syntax didn't make any application of the Perl language that previously would have been impossible suddenly become possible. In fact, Perl's switch statement has been mostly repealed (or flagged as experimental) in modern releases of Perl.

given/when is a programmer convenience, not a language necessity. Use if/elsif/else, or a hash table filled with code refs, or if you're concerned about efficiency, use an array-table filled with coderefs, and assign constants that refer to the elements. Even if you're trying to make your decision based on pattern matching, that's not difficult:

use constant {
  RE_TRIGGER => 0,
  CODEREF    => 1,
};

my @dispatch = (
  [ qr/this/, \&do_that ],
  [ qr/those, \&do_these ],
);
DISPATCH: for ( @dispatch ) {
  $string =~ $_->[RE_TRIGGER] 
    && do{ $_->[CODEREF]->(); last DISPATCH; };
}
[download]

In this example I'm populating an array with a series of patterns and actions to take if a given pattern matches. I have control over which match is tested first, because I'm using an array for the dispatch table. And I have control over whether to continue on to the next test, or abort upon success by the use (or omission) of last DISPATCH. I can even add a default by including a regex test as the last element in @dispatch that will always succeed.

Is it more clear than a series of if/elsif/else statements? I guess that depends on how many tests are being conducted. If it's just a small few, chained if/elsif's are probably clearer. If there are a lot of options, a table works well.

If you make the first element a subref instead of a regexp object, you have even more control, and a more generalized solution.