☑ Read a book on Perl or on-line manual pages, blogs, articles, ...
☑ Written a book on Perl or reviewed a book or contributed to a book
☑ Contributed to the Perl source code so you'll learn to find the edge cases and recognize vulnarabilities
☑ Debugged someone else's script Always a learning experience
☑ Played Perl Golf esp to learn about special variables
☑ Used regular expressions to save the day always helpful for quick results. No read the book again and start learning all the flags and markers :)
☑ Used Perl for a certain amount of time (please specify) Daily since 4.018
☑ Invested a certain amount of man-hours in learning Perl (please estimate) On the job
☑ Visited at least x Perl related events also to get new (sick) ideas for modules or module features
☑ (Co)maintain at least x active (up-river) CPAN modules to learn what the rest of the world expects of perl and the sick things they do with it. Also to write documentation that is actually read
☐ Forgotten you were not Larry Wall
☐ One can never truly know Perl One can not truly know *all* of Perl, but you can certainly learn enough of Perl in the area you want for your project. It is not required to know every tiny detail about floating points and internal behavior if you only use integers. You don't need to know about threading implications if you never use threads (unless you write XS code that might be used in threaded perls). You don't need to know anything about <c>format<c>s to have a decent Perl project. You don't need to know about locales and encoding if all you do is number crunching.
Enough Perl knowledge to convince a prospective employer that you "know Perl" sufficiently to hire you, and then know how to learn and use sites like PerlMonks to be able to figure out any problem that is thrown at you. :-)
edit: fixed an obvious English error and slightly reworded so it fits better as an answer to the original question.
Just another Perl hooker - My clients appreciate that I keep my code clean but my comments dirty.