Anyway, I think it's a great idea to get those missing features back by including polyfills in your project. Over time, less and less of your code will be executed and it'll still be working! Isn't it great?
One more thing before I'll dive deep: I would only advise those of you who consider themselves already "more than just jQuery developers" and have some experience with design patterns to try this, it's easy to make a mess when you don't have a clue what you're doing.
So those engines are a lot of code, which we only need for IE <= 7. Somehow we'll have to include it for IE <= 7, but not for all the other browsers. Polyfill to the rescue! A while ago when I needed exactly that, it wasn't there yet, so I put my own polyfill with Sizzle together, you can find it as a Gist on Github. It's really only the engine with a wrapping function around it, if the spec is already implemented by the current browser, it doesn't do anything at all, but if it isn't implemented, it polyfills querySelector() and querySelectorAll() with Sizzle immediately behind the functions.
EventsEvents are more easy, you can just implement those yourself, or at least you don't have to steal a lot of code. There are of course 2 event models, W3C's and Microsoft's. The most simple solution would be to take John Resig's addEvent(), it'll most likely suffice. And I wouldn't even include removeEvent() until you need it, I very rarely use it.
DOMDepending on how much you started using the traversing functions from your library (next, prev, parent), you could start working manually with the methods and properties of Node, Element and Document. That should get you everywhere you want. If you'd rather have those shortcut methods back, have another look around on microjs, there's a lot over there.
Sticking to the jQuery example, in the case of manipulation, most methods used will probably be attr, html, val, and maybe some append or prepend. These are easily replaceable by methods of those same Node/Element/Document objects. But! Those DOM objects are really buggy implemented in almost any browser, and that's what your library is fixing, abstracting it away for you. You should try working with the browser objects, and see if you can handle the bugs. If it's not that big a problem for you, stick with it! If it is, maybe you should plug-and-play a micro library in that does the DOM stuff for you.
You might also not be willing to wait for window.onload(), and prefer the faster document.ready() and other equivalents. Again you have several options here, but I'm going to steer you to the fastest and smallest one I know of, Dustin Diaz's ready.js.
HTTP RequestsThese are quite similar to events, there's W3C's and Microsoft's object. Luckily, we can forget about the Microsoft one, since from IE7 and up, W3C's XMLHttpRequest object is implemented in IE. This object is really easy to use, so I'd advise to use it directly. If you're really going to use it a lot, you could wrap it with a small function to make it slightly easier to use, but we're talking syntaxical sugar there. You could also go see microjs again if you're lazy.
And make sure to structure your code nicely to keep it all maintainable. It's more important now your code base will be bigger. I think my next article might be about that.
And as a closing note I would love to hear from all the problems everyone bumped into when trying this, and what solutions you picked! Cheerio!