I don't believe encoding the "why" is possible.
The mapping from "why"s to "machine code" is not predefined bijective nor injective.[1] It can't be well-defined enough to make a deterministic compiler. If you restrict the set of "whys" to a very narrow set of "understandable" inputs by the compiler, you've basically re-implemented the specifying of the *"whats" again.
Building ever higher abstractions is tractable because it's what we've been doing for decades: combine several lower-level "whats" into higher-level "whats". But encoding the "whys" seems to be unsolvable. Either that or I'm not understanding what you're communicating.
Wasn't C a reaction to assembly languages not being portable enough? Weren't assembly languages a reaction to machine code not being easy enough to work with? Wasn't machine code a reaction to punch-card systems being too inflexible? Etc. etc.
I'd say these problems are technically difficult, just not deep. To clarify the difference:
(0) A difficult problem requires a lot of effort to solve. Example: Finding and fixing use-after-free errors in a buggy C program.
(1) A deep problem requires creativity and insight to solve. Example: Inventing and formalizing Rust's borrow checker rules.
Programmers are naturally attracted to deep problems, but not difficult ones. In fact, reducing difficult problems to deep ones is often considered progress, for good reason. After you come up with the right insight, solving a deep problem can be very easy. But solving a difficult problem will always be hard.
Edit: Besides that, I agree, except one thing, I'd say C# is just MS's reaction that there is something awesome which does not belong to them.
Really, C# is a public service to correct for something that for so many reasons should be awesome having turned out so-so at best.
(You may say writing a million getters and setters, declaring types twice, stuffing your code in deep directory hierarchies, and dealing with bizarre licensing/version issues feels normal; that's the Java talking.)
> C++ was created as a reaction to OOP being so difficult to do in C.
> Java as a reaction to memory management being difficult.
> C# as a reaction to Java not being concise enough.
> Javascript as a reaction to HTML not being dynamic enough.
> Go has a reaction to parallelism/concurrency being difficult.
> Rust as a reaction to what C++ has become.
And it goes on. There are many other languages too that you won't hear of that are created as a reaction to the status quo not being good enough either, but those ones I listed were backed by a big enough majority to become known. There is also the Lisp family and the functional paradigm too, which come round again and again in popularity.
All these languages/tools are the problem because no one is sitting back, and pro-actively realising that the entirety of these languages are no good. I am not saying this to start an argument, I have happily been a programmer for 15 years. But I recognise the problems, and they are the same problems, that will repeat over and over again ad-infinitum. I actually started writing down problems I've found and possible solutions and it's already reached over 30 pages.
What it boils down to is that all languages share the same flaw; they specify the what and the how, but never the why. Until we figure out how to encode the why, we will forever be going in circles.