Just to throw another opinion into the mix: Sometimes one sees such variables strictly titlecased, since they're package variables but not constants, like for example the options in Data::Dumper (e.g. $Data::Dumper::Sparseseen or $Data::Dumper::Maxdepth). So for example $Data::GUID::Any::Uc may not seem to make as much sense as uc or UC, but it indicates it's a package variable since it's titlecased, but not a constant since it's not all uppercase. (I see kcott posted the same point as I was writing this)

The casing of variable names is just a convention and not a strict rule. Anyway, if you want my opinion on the following:

I need to provide a package variable in a module I'm working on to let the user turn on or off a feature. It's a simple non object oriented module. I've used Data::GUID::Any before and remembered there is a package variable called UC that is used exactly like what I want to do.

I would suggest not using a package variable at all. Despite the longer names, they're not really different from other globals like $/, and come with all the same potential issues: One has to remember to use local, and even then, dynamic scope might bite you lower down in the call stack. If you don't want an OO interface, then give your functional interface parameters to configure options.

use warnings;
use strict;

{ package Foo;
    our $DEFAULT_BAR = 1;
    sub foo {
        my %opts = @_;
        $opts{bar} //= $DEFAULT_BAR;
        print "bar=$opts{bar}\n";
    }
}

Foo::foo();          # prints "bar=1"
Foo::foo(bar=>2);    # prints "bar=2"
[download]

I usually set up package variables like $DEFAULT_BAR such that I can easily change the defaults, this can also be useful for testing, but I also usually leave them undocumented since I don't want to encourage the use of these globals. Also the above code could of course do some validation on foo's @_, but I omitted that for brevity.