I think you need to meet in the middle. My approach to this problem is to recognize that most people work in a subset of Perl, and then go out and conciously decide what subset you will work with. Once that is decided you know what you need to teach people to bring them up to speed, and you know when you to go to the Perl experts and say, "Nuh, uh. Distributing a backslash across a list of variables, several of which you are in the process of declaring, is not a syntactic trick that we expect people around here to follow. So remove it."

You have to do both simply because there is so much Perl out there to learn that you cannot bring people up to speed on it. Besides which, there is no person that you are better off losing than the guy who so enjoys coming up with obscure syntax that he cannot read his own code 6 months later.

An extreme example of what you can do would be Re (tilly) 1: to perl or not to perl. (That was for using Perl in an environment of non-Perl programmers. Living within those rules is doable but painful.) My personal list has a lot more than that on it. For instance I want people to understand OO, anonymous functions, closures, and other high-order concepts. (I also don't expect people to pick this up in a short course.)

As for how to get people thinking Perlishly, I would suggest first making sure that they have access to the Cookbook and spend time looking things up there. I would also make sure that they got the pep-talk about why using foreach reduces mistakes, and why hash lookups are better than explicit positional logic or scanning arrays. (Hash lookups win on maintainability and performance.) I would consider a pep-talk about list-oriented ways of thinking being good.

And then follow up with code reviews. Ding people for using explicit for loops. Ding people for using positional logic when they didn't have to. Ding people for any scanning logic which isn't justified. (Unjustified essentially means that overall it is bad algorithmically.) Point out where they can use hashes. Oh right, and be sure they use strict.pm.