Going further, my impression is that people who are familiar with other dynamic languages are more likely to want to reach for something like AUTOLOAD (perhaps they'll call it method_missing, but they expect it to be there) than they will can.

I dont know if i agree with this, I can see where AUTOLOAD can be a nice tool, but I wonder if you are not restricting your view of can too much. In alot of ways they are similar, can being just a more manual approach. I think people who might be comfortable with using class reflection would be more likely to go for can, where as those more familiar with run-time code generation would reach for AUTOLOAD. Both are common aspects of dynamic languages though.

I think that you hit it in this paragraph. My background/interest is definitely for run-time code generation of various kinds. Class reflection is simply not really to my taste.

That would make me more aware of the equivalents of AUTOLOAD in other languages, aware of its uses, and inclined towards caring more about it than class reflection.

For me OO is a tool, not an ideal. You can feel free to apply pejorative terms to me for what results from that attitude, but insults won't rearrange my priorities. If I feel inclined to use an AUTOLOAD, and I think that in the situation where I'm using it, it is justified (which is in actuality rather rare), then I'll use it and not be bothered overly much if I leave can broken. (Unless I'm working in a code base where can is already in use, in which case that fact would factor into my decision about whether to use AUTOLOAD.)

I don't think that that is wrong, nor do I think that I'm alone. I'll admit, though, that most people who fundamentally agree with me haven't necessarily thought the matter out as much as I have. Then again I don't think that most who disagree have thought about it that much either.

Incidentally where I have seen AUTOLOAD most commonly used with objects is in a base class. All classes which inherit are supposed to play nice with the AUTOLOAD, and there are no other AUTOLOADs in the class hierarchy. An example of what that AUTOLOAD might do could include autogenerating a standard basic interface, including a list of accessor methods. (That would be where I'm inclined to typeglob closures instead.)