Making modal editing with a leader key the default rather than an option it currently is, is a pretty trivial thing to bring up as the stand-out "feature" a rewrite could provide.
Though trying to run Emacs like vi is a pitfall in itself. Clunking around the terminal summoning Emacs to edit files is really not a particularly effective way to use it. Emacs is not vi, and using Emacs like Emacs makes more sense. Most users explore your filesystem and spawn and monitor processes from within Emacs, rather than from a terminal.
Not that you can't work that way (and using `emacsclient` is the way to do it), but you're losing out by trying to shoe-horn usage patterns familiar from other toolchains onto Emacs. Emacs is not a text editor, it's a text manipulation platform that includes an editor - a number of editors in fact, including a vim clone.
> 3. There might be a way to do this but I'm not sure. Emacs being inherently single threaded probably makes this difficult. But yes, I use M-x (re)compile.
Emacs has zero issue with multiple compilations - they're handled asynchronously. If threading was an issue it would kill Emacs with just one active compilation let alone many. The lack of threading in Emacs is a significant issue, but simultaneously nowhere near as restrictive and troublesome as many people seem to believe.
It's irritating that Emacs inhibits simultaneous compilations by default, but that's literally simply down to buffer naming. Emacs uncompromisingly uses a buffer called "*compilation*" for compiliation and will only run one at a time in a buffer.
There are simple hacks floating around to have compilation create a unique buffer name, then it happily runs as many as you like. Also, `projectile` has the setting `projectile-per-project-compilation-buffer` which enables this by putting the project name in the compilation buffer name.
I do echo the sentiment that it is not an easy out-of-the-box experience, and the learning curve is steep, though this is the sort of configuration that I assume the likes of doom set up by default. But even then, starting with doom is a much more significant endeavor than starting with VS Code.
But once you learn and develop your Emacs set up it becomes a delightful, malleable, and extremely powerful environment that's comfortable like an old leather chair, and where it isn't, you make it just how you want it. Some of us were lucky enough to accumulate proficiency over years and decades starting in a time when there weren't easier options with comparable power.
I love to have people join us and appreciate it, but it's not an easy process to get to the payoff.
I wouldn't move to ivy today, though ivy is great. I moved on from it to the vertico/orderless/marginalia/consult/corfu type stack and it feels at least equivalent to me, but the implementation is more integrated with built-in Emacs and I think it will have a stronger future. Not that ivy is bad, or a generally inferior user experience.
I have to say I don't particularly see the wisdom of this (common) view.
It's acceptable to people to use the standard Elisp, and Emacs itself, without digesting that code, but somehow using a canned config is bad. I find the choice of where to draw the dividing line somewhat arbitrary.