I think that the idea behind this project is to simplify Emacs' code, e.g., by dropping support for ancient systems (they mention MS-DOS) and using pre-existing crates instead of in-house solutions. A simpler codebase might provide significant advantages for end users as well: (1) there will be less bugs in the code, (2) finding and fixing these bugs will be simpler, and (3) new features and structural improvements will be easier to implement. Of course, users will actually switch to Rustmacs only if they will be 100% compatibile, i.e., if Rustmacs can run every Elisp code in the same way as Emacs does. It's surely a very ambitious project!
Yes, I use it every day, at work and at home between different computers. I have a few windows-nt specific lines in my .emacs, mostly to set paths to grep and the like but otherwise have no problems and it is pretty indistinguishable from using it on linux systems.
Could you perhaps elaborate on the problems you are experiencing, since otherwise I really have no idea what you're talking about.
I wrote this Common Lisp script to pull the tip of the official Git repo, and then build and install. I run it every few months if I need to restart Emacs for some reason. Works (for me) on Linux and OSX without out a problem. I've been using it long enough that I had to update it to use Git instead of whatever they used before, and I don't recall ever having a build error once I installed the dependencies the first time.
I know it's cool to hate on Windows but some of us have to work with operating systems that support the tools we use.
Rust has phenomenal cross-platform support so there's no need for scripts or multiple dependencies. It's just a simple "cargo install <foo>" and away you go.
Emacs, on the other hand, has some pretty big system dependencies (like gtk3, alsa and imagemagick on a modern linux) and one step of compilation where it actually loads up all the elisp stuff (which is really slow to load), then dumps the memory holding the loaded elisp stuff, and on next startup it just reloads the dumped state into memory. Somehow I strongly doubt that's going to be a simple "cargo install foo".
Well that's kind of silly. Unless you're contributing code to the Windows port of Emacs itself then there's no reason I can think of to build from source instead of downloading the prebuilt Windows binary from the GNU ftp site. They have pre-built 32 and 64 bit versions, each with a variety of options http://ftp.gnu.org/gnu/emacs/windows/
Even if that's not feasible for some reason, setting up the build environment is a one time sunk cost, so who cares?
I build from source at work because I'm still using an ancient version of Ubuntu there, and "apt-get install emacs" installs version 24.something.
At home on a modern Debian system I use "apt-get install emacs" and it works just fine. I did test that build script on OSX, but the one I actually use is from https://emacsformacosx.com/
Using Common Lisp instead of ELisp would be useful enough that I might switch.