Some thoughts/braindump on possible next steps:

1. a gameplan would be great. Since there's a lot of moving parts between the rust compiler, MIR, binaryen, webassembly itself, and psosibly other helpful tools such as miri and emscripten, it's hard to have a precise vision of what to do immediately.
2. we could work on supporting more rust types, and more of the wasm types. Right now we only emit i32s out of the 4 wasm types for instance. (trans_operand panics if a value is not a Rust 32 bits isize, the binaryops emit the hardcoded i32 versions of those instructions, etc)
3. related to types and variables, is memory management, which is the point of issue Memory management #11 - what would be the best way to proceed there and so on. (Meanwhile we could prototype the manual version @kripken described there)
4. we could work on better operator support, both more rust operators and also wasm ones. I was trying out the PartialOrd ones, and this requires many traits and impls, Options, #[derive]. Related to point 11.
5. we could work on supporting more of Rust control flow and constructs, like match statements. (I was wondering whether br_table existed in the binaryen API ? -- since it looked interesting for this use case but I didn't investigate it very much)
6. updating to a newer nightly (even though Update code to work with nightly 2016-06-04 #8 mentioned apparently that there might be some issues to do that). For instance there have been recent simplifications regarding locals (with AFAIK some code very similar to the ones that exists in the backend in trans_lval)
7. infrastructure-wise, tests like mentioned in Testing #15 with validation, scaffolding generation, execution, etc would be definitely helpful
8. how to handle wasm specific features, like imports and exports, prints, or their intrinsics. Right now we emit say Add::add code even though it's not used by BinaryOps since wasm has i32.add for instance.
9. when would we have to deal with wasm32/wasm64 and how would that impact us (probably not much apart from maybe memory management)
10. at some point maybe documenting some Rust/MIR constructs and how they should map to wasm: it could document what exists and works, and explain the things that are left to do and how to do them
11. maybe some goals ? what kind of features would be expect to support and "when" even just for dev. So an idea here would be interesting: would we expect mir2wasm to compile some/all of the Rust std/core library directly and package that to the browser, or support something limited like no_core ?
12. after speaking with @eddyb and @solson Miri could be very useful, it has some utilities all backends need (and could even be a layer between us and the rustc_driver which could make upgrading to recent nightlies easier). e.g globals/constants/statics https://botbot.me/mozilla/rustc/2016-06-22/?msg=68388125&page=1

update: typo