With regards to extension to elements accessed with $ or $$, the list of mix-ins is large, but incredibly useful:
http://www.prototypejs.org/api/element

With regards to globals and object extension, I am almost amused at their confidence at times. Indeed, even their self-penned description of DOM elements is a little dramatic:
“Before you pursue, you really should read “How Prototype extends the DOM” which will walk you through the arcane inner workings of Prototype’s magic DOM extension mechanism.”

Arcane and Magic?
Really?

In the end, though, no one is putting a gun to our head - and we can very easily hack the source.

We can’t ever forget that most of that library is directly inspired by “The Ruby Way” - they do what works for them, and it seems to work for a lot of other people as well. I encourage anyone who thinks Prototype’s approach is insane to take a look at “Programming Ruby”:
http://www.amazon.com/Programming-Ruby-Pragmatic-Programmers-Second/dp/0974514055/ref=pd_bbs_sr_1/104-6382103-6883909?ie=UTF8&s=books&qid=1181320753&sr=8-1

If you find that the syntactic sugar is tasty, then it’s worth checking out the YUI Element utility.
http://developer.yahoo.com/yui/element/
Rather than attach these helpers to every element, YUI gives you the tool to attach them yourself where and when you as the developer feel it’s most appropriate. It’s not intended to be applied willy-nilly to any and every Dom element.

I too find the ‘$’ Function to be useful. I also tend to import the ‘$F’ Function and a few others as well. My build process includes a file ’shortcuts.js’ right after the Framework files where I define about 20 shortcuts.

If you find yourself using a Framework with long namespaces like ‘YAHOO’ then defining ‘$’ to the ‘get’ method as Isaac mentioned can also reduce file sizes by a measurable amount (2-10%).

On a less positive note, be careful about using syntactic sugar, as it is very easy to catch yourself in a circular reference. For this reason, I avoid using it.

On a less positive note, be careful about using syntactic sugar, as it is very easy to catch yourself in a circular reference. For this reason, I avoid using it.

I’m not sure what you mean by “catch yourself in a circular reference.” I do firmly believe that any syntactic shortcuts, along with other global variables, should be kept within a local scope. That prevents collisions. Circular references are only a problem if they cross between Javascript space and DOM/XPCOM space. http://foohack.com/2007/06/msie-memory-leaks/

Circular references *within* Javascript space are natural and common. Consider, for example, the reference chain that connects an object to its constructor and prototype:

var X = function () { };
X.prototype = { constructor : X };
var y = new X();

The X function, via its activation object, has a reference to “y” variable. Via the constructor property on the prototype (which is always there, whether you specify it or not,) “y” has a reference back to X. Or even more obvious, and just as harmless:

var a={};
a.b=a;

The variable can now be referenced as a.b.a.b.a.b.a.b.a.b… Though it would of course be silly to do this, it won’t cause any problems beyond the extra lookup time. The minute “a” falls out of the available scope, the mark-and-sweep algorithm will clean it up.

Circular references that cross into DOM/XPCOM space *should* be just as harmless, and in most browsers they are. Unfortunately, IE 6 is the browser that is used most, and it is the one with the memory-leaking bug.