Just like the C lint, the goal is to point out potentially unusual things
in the code. You're right, figuring out true intent is non-trivial so I
won't sweat the nuances. Instead, I'll just console.log a message and the
user can decide whether to ignore it or not. It doesn't need to be really
smart, just really observant. I would be embarrassed to tell you how many
times I've said $("myid") when I meant $("#myid") and spent 10 minutes
trying to figure out what was broken.

Perhaps the plugin can have an option to turn off certain messages and the
user can avail themselves of that if the volume of spurious messages is so
high that it obscures the useful data. In most cases I want the usage of the
lint plugin to be simply whether you include jquery.lint.js in the page or
not; there shouldn't be any need for the user to "set it up" via a .ready
handler. That way it can be taken in and out with no fuss.

Re DOM properties, I was planning on using __defineGetter__ and
__defineSetter__ in Firefox. If someone tries to set/get the .style or
.innerHTML of a jQuery object then it will honk at them and explain that
they are trying to use a jQuery object like a DOM object. It can all be the
same warning function so it's just a case of making the list of forbidden
properties and hooking them all to that function in jQuery's prototype. This
is an incessant FAQ on the group so a tool to catch it should help a lot.

Not all of them are outright errors but the goal is to point out potential

problems or cleaner/safer/faster ways to do things, especially for
novices.
Like John's original plugin, it would wrap around the existing api and
not
require any code to be inserted into the jQuery source.