(global-set-key "\M-w" 'copy-region-as-kill)
(global-set-key "\M-w" 'copy-region-as-kill)
Emacs periodically surprises me by already having some minor function I wanted, but half the time it's only surprising because it's named something unusual (compared to both other programming environments and the rest of Emacs). I can never remember what the commands are called for "get (point) for beginning / end of line", just that they're named something I can't find by searching apropos with anything that comes to mind, so I use something like
(defun end-of-line-point ()
(save-excursion (end-of-line) (point)))
While, on the one hand, it's nice to be able to extend the editor so easily, solving the underlying problem wouldn't detract from its extensibility in any way. Sticking everything in one namespace also leads to function-with-unnecessarily-cumbersome-name syndrome. (C has the same problem, though.)
Maybe one of these days I'll quit whining and just write another editor, but any real competition to Emacs has a lot of functionality to match, and most of the other historical cruft is easy enough to tolerate.
I was going to post my thoughts on the impossibility of a (require 'sane-emacs) but then I found this document on "Emacs2010": http://code.google.com/p/emacs2010/wiki/DeveloperIntro
I have a strong suspicion that there are various subtle factors in the design of Emacs that encourage people to re-implement things in elisp, rather than just use existing programs. Elisp has external process calls, but it still seems like this blob that turns half of what it touches into something that will eventually be rewritten in elisp. (Perhaps part of it is that Emacs all runs in one thread, so background processes make it freeze.) I know many people love working in Lisp, but I'm pretty sure it's the last Lisp most people would choose under any other circumstances. (I'd rather use Scheme.)
There's a lot of stuff that doesn't need to be running inside the editor. Its core could probably get by fine on undo/history management, file and buffer management, syntax highlighting, a keybinding system, a generic comint-like mode for shells and interpreters, other external process call functions, and ... what else? (Acme & Wily do all of the above except syntax highlighting. I'd use it, but I strongly dislike mouse-centric UIs.) I know that's a fair bit of work, but it's not like one would have to rewrite all of gnus and whatnot. Even something like query-regexp-replace or pabbrev could be an external process.
I've also been wondering if there's a good way to make the parser system used for syntax highlighting separate, but haven't settled on anything yet. (Parsing text that is changing as you parse it is a fundamentally different problem than parsing a static file or stream, and a relatively unexplored one, as this blog post notes (http://www.codekana.com/blog/2009/04/02/on-the-speed-of-ligh...).)
Finally, I think that Lua would be an excellent choice for the customization language. A lot of Emacs's warts are ultimately issues with elisp, itself. (And, while Lua is my favorite language, and I'm admittedly biased, such use as an extension language is one of its major strong points.)