I'd add three guidelines from perlmodlib to your naming list:

• Generally the name should reflect what is special about what the module does rather than how it does it.
• Avoid any risk of ambiguity.
• Always try to use two or more whole words.

A name like "Object::Voodoo" really doesn't say anything abuot "what the module does," in other words, about the public functionality.

Similarly, Object::Dynamic and Class::Less seem ambiguous: starting from the name, there's very little chance that people would be able to guess what the module does, because there are so many other things that could be meant by "dynamic" or "class-less".

I would suggest finding a name that was more explicit about what the module does: it uses designated package variables as accessors for object instance values. (Right?) So your package name should reference those key concepts: object instances, and locally-scoped package variables.

Rather than shortening your current name of Object::Local, I'd lengthen it to Object::LocalVars. In the context of Perl, I think that people will rapidly parse "local vars" as "dynamically scoped package variables along the lines of local()."

I understand that you want the class name to be short, but since you only have to type it once per file, I think this is a mis-directed optimization. The extra few keystrokes in the name are a small price for people scanning a list of module names on CPAN being able to guesstimate the features it provides.

Update: If you'd a terse and "catchy" interface, provide an optional props.pm psuedo-pragma that delegates to the main class so that people can write use props; mad props, G; our $name : G;. People who are looking for something "wierd and different" can use this interface, while people who are looking for something practical will be able to understand the primary module name.