Thanks for writing this up! Here are some personal bits of feedback, wearing my Servo & Firefox hats. Obviously, these are places where we might be willing to make investments from our side to assist in making them happen, as appropriate.
First-class Windows support
Things are getting much better on Windows, but the debugging experience, native interop, etc. need one last “push” to close the gap. This is super important for desktop browsers, as >90% of desktop usage is Windows, and today developers really don’t like to try to work on Windows, partially because of toolchain issues.
Make Rust/Cargo first-class citizens in big build systems
There are a few more small gaps here (e.g., [replace] usage, host vs. target rustc flags, being able to compile the stdlib as part of the build, etc.) where giving an inch will prevent big build systems from doing stuff like their own custom rustc builds or reverse-engineering crates.io hash procedures / building a custom cargo binary to avoid policies. There are also some simple tools around cloning a dependency to open a PR & setting up all the local environment bits that would aid in the frustrations big build folks (and Servo developers, tbh) feel with hundreds of dependencies.
Finish off a Rust semantics
I get a bit worried because this has lingered with a lot of partial efforts for a while and there seem to be lots of pushes for integrating pieces of language features that are known to interact badly (e.g., when traits, modules, and/or HKT co-exist). Haskell gets around this a bit with their language features, which are just assumed not to “play nicely” together and to not be on any standardization/stability path, but so far as I have seen people don’t have the same assumptions about new Rust language features hidden behind unstable. Without getting some sort of tooling or framework in place for checking whether an extension is semantic sugar or deeper, I’m worried that as the language continues to grow in complexity, more safety holes will sneak in.
Some small elaboration on other high-level bits of the original post:
FFI
Does this include support for inheritance-like patterns in Rust, as needed in the DOM? IIRC, this gap is still responsible for the vast majority of Servo’s unsafe code. Is there something we can do to help that move along this year? I think it’s now entering Year 4 of work on that, and we should either finish it or decide it’s never happening 
Concurrency and parallelism
I’d love to see some more ideas around stuff that could reduce the number of threads. I’m a bit worried here because, especially on 32-bit platforms, we’re finding that with hundreds of threads we end up going OOM and failing thread creates with Rust due to the combination of address space fragmentation and base reserved stack. Further, hundreds of threads just doesn’t work all that great on some of our platforms. These problems will probably lead to ad-hoc solutions that kill our nice architectural separations provided by the use of thread boundaries and channels.
Rust should have a lower learning curve
Have you considered reaching out to a user research group? There are several places (academic and commercial) that do formal user studies, recording first-time and experienced users working with a programming language, and then distilling that into some takeaways (possibly publishing a paper, as appropriate ). I’ve found that very useful in the past.
