I think the most important part is figuring out who is going to use the PL and what problems they are solving. As precisely as possible, best with a list of concrete Personas and Projects. This creates a "value system", which makes it easier to answer all questions during implementation.
Absolutely, just look at Haskell as an example.
> most important part is figuring out who is going to use the PL and what problems they are solving.
Completely agree. Rust and Go have received a lot of criticism over the years, but I think that is often down to them not being as general purpose as many people try to claim. The creators had particular users and use cases in mind.
It is. Language features generally aren't isolated modules that you can add and remove freely: they interact, and "the good parts" are only good because they play nicely with everything else. You can't have Lisp macros without Lisp (or otherwise homoiconic) syntax, or Haskell's concurrency without its effect tracking, or global type inference with Java-style inheritance.
Is that the claim actually that they are general purpose, or do people not understand the claims made? Go has been very explicit that it is designed for systems programming. The Rust camp seems to hold a similar position. "Systems" implies that it is not designed for all tasks. But I'm not sure "systems" is properly understood by a lot of people.