Indeed, both the the things that you mention would be very important improvements, but I am not aware of any plan at the moment:
64bit vs. 32bit is in principle invisible to _javascript_ (since there are no pointers), but Emscripten has to pretend that it is a particular arch when compiling existing C++ code, and at the moment it only pretends to be a 32bit arch. For most code, there is little benefit in having Emscripten pretending to be a 64bit arch, but of course, for us it would be very nice as that would mean more registers. I'll draw Emscripten developers' attention to this point. I suppose that a major hurdle to overcome, is that _javascript_ doesn't have a native uint64 number type, so handling of 64bit pointer arithmetic would be inefficient. As a result, I guess, all pointer arithmetic would be a lot more inefficient. But that's just my uninformed guess. See comments on 64-bit integers in
https://github.com/kripken/emscripten/wiki/Code-Generation-ModesAVX/FMA would be very nice, but at the moment, it looks like the browser world is still trying to ship "any SIMD at all", with the initial target of SSE2 still being in the future: it's only efficiently supported in Firefox Nightly at the moment. So it's probably a matter of, "one thing at a time". There might (or might not) also be a typical concern in the Web world, of introducing compatibility issues when some new feature is only well-supported, or only fast, on a subset of client machines. That kind of concern generally makes the browser world err on the side of being conservative. Which is a good thing in general, just not for us!