By the time we have native compilation, I hope also our Elisp implementation will be significantly faster than the one in Emacs, so it will really become attractive to people to finish the work that we have done to make the switch there.
Replacing Emacs elisp implementation is just looking for trouble. Although it is not the fastest one, the existing one works well enough and is battle tested and there are millions of lines of elisp code that would need to be tested, debugged and fixed.
If the goal is to allow to write parts of Emacs and extensions in some other language, I wander is Scheme really the best choice? Why not go all out and implement elisp in Common Lisp and use Common Lisp as a base for future Emacs and extensions development. There have already been such attempts, so it's not exactly something unheard of.
If there was an actively-developed common lisp implementation that also ran elisp, I would be all for running emacs on that as well.
Emacs' sheer size (which you mentioned yourself) means you're not going to port it to a different language and have something comparably useful in less than a few years, assuming sustained interest and full-time development.
So, does 2.0 have up-arrow history and in general not freak out when I try to do stuff in interactive mode? Guile's great for what it's great at, but interactive dev. in the custom of Python or Gambit Scheme isn't one of those things, at least for me.
They talk about ELF for storing byte code? Would that work on Windows/OSX?
(I guess it would, as much as Mono can load PE .NET files for OSX/Linux, after all these won't be loaded directly (it won't make much sense without the runtime anyway))
For an emacs user, that's pretty exciting.