Yes, they are a part of the API, just as much as symbol-tables are ... depending on how you define "API". I'm not talking semantic quibbles here, but a real difference between definitions.

I'm not choosing to "ordain" or "deprecate" anything. I have a personal line in the sand, and I do understand that the line is my line and only my line. That line is the API line. If I cross it, I am mucking about with the internals.

Unlike Java or VB, the API line isn't the Berlin Wall, made of concrete and topped with concertina wire. It's a line with lots of gray areas - it's actually more of a "zone" than anything else. It's a zone that, IMHO, one should enter only upon careful consideration of the benefits and drawbacks. It's the zone that, in my experience, separates those who sling Perl code and those who understand Perl programming.

Now, if you choose to cross that zone, you (hopefully) are conciously desiring to have some of the restraints and limits lifted. It's no coincidence that you usually have to disable at least some portion of strictures to muck about on the other side of the API zone.

It's also no coincidence that code written on the other side of the zone is almost never self-documentable. This is the code you spend 2-3 hours in a code review explaining how the darn thing works and you end up with a decent lecture on some portion of the Perl internals. I'm talking about the Damian side of the world. You know, the modules he writes, then puts in the documentation under BUGS something like "There almost have to be some bugs in code this funky."

Not every use of any feature I would mark as being beyond the zone qualifies. But, for every simple usage, one can think of two usages that aren't so simple. That's why it's not a hard-and-fast line; it's a zone.

As for your last comment ... I was arguing for self-discipline. If you want to go ahead and muck your own application up, that's your own damn fault. I don't have to maintain it, so I couldn't care less. I don't want to be involved in how you do your code.

What I was arguing for (and which was completely unobvious) was changing how the community through docs and sites like this present these capabilities. We already strongly dissuade people from using symbolic references, a feature I think most of us would consider beyond the API zone. Why should it be any different for AUTOLOAD, symbol-table manipulation, tie, and other, similar features? We can argue about which features and sub-features truly belong in that zone, but I would hope we agree that there are certain areas newbies shouldn't enter, for their own sanity. The Llama book doesn't discuss AUTOLOAD, save in very general terms - that's saved for the Camel. Same with tie, eval, and s///e(e(e)). No-one complains about that ...