OK yours is the second comment to talk about "Users". IMO this first-impression-based design methodology, like we're writing some consumer CRUD app for the startup [proverbial] you're gonna quit in terrible skeumorphic philosophy for designing languages. Languages are for more terrible; programs last (too?) long; long-future readers may be expert or knowledge.
Let me response point-by-point
> It's not a thing your users see. The "syntactic sugar", as you call it, is the interface between you and your users.
Users can and should learn the core language too. It's can allow compressing the information in the brain just as it allows reducing the code in the implementation.
> In a good world, they do not care how the rest happens in practice.
Again, I believe the core language is a meaningful thing to study and learn, not just some shove-under-the-rug implementation detail. You clearly don't, and your conclusion is indeed implied by that presupposition. It's hard to argue either from other principles so let me say it is widely held by those that study programming languages and work with cutting-edge programming languages: My axiom has more buy-in by the relevant in-groups. Maybe out-groups with yours are right and we are bad designers, or maybe those out-groups should accept a non-trivial learning curve vs permanent complexity.
> The lower levels do not drive the higher level in roughly any case.
This is wrong. As someone active with RFC discussion for both Rust and Haskell, this empirically not the case. Ideas are constantly proposed and vetted based on whether they fundamentally extend expressiveness or are just sugar.
> First you understand what users want at a high level
Yes, languages changes should and are be driven by end goals, but end goals != surface syntax!!
> There are nothing but tradeoffs in mid level IRs
What does this even mean? Surface syntax is full of tradeoffs too.
> those tradeoffs change over time based on the needs of languages, not the other way around.
Again, once the MIR/core exists, RFCs heavily reference them so this is false.
> Driving a language based on what you can accomplish in a mid level IR would be incredibly silly - "Welp, we better use this form of parallelism at a high level because we chose coroutines in the mid level IR" should never occur. Instead, the answer is "we change the mid level IR to best support the form of high level parallelism we want in the language".
This leads me to think you don't know much about IRs in these langauges in practice. Neither Rust's or Haskell's IR has any notion of concurrency precisely because nothing good enough has presented itself. Both language use syntactic / "encapsulation tricks" (See Haskell using the IO monad to avoid the value restriction of OCaml, Rust's Send and Sync) to chew off some safe subset that works with many modules. An IR with a deep/"semantic" understanding of concurrency doesn't exist for these "production" languages, though I hope http://plv.mpi-sws.org/rustbelt/ could get Rust there someday.