I agree there is a lot of room for new languages, however I am not quite sure that another general purpose language is the answer.

The whole problem of general purpose language is, well, they're general purpose. That's fine if you'd write general programs, but very few do that. Everybody else solves his/her specific problem with the language. You usually can get around the language limitations just fine (and we do that so often, it becomes a natural fact of life). Obviously, you can make a few different choices in the language, and be more expressive at one point, or less expressive at another point, but it remains general purpose, where every problem mostly fits (and some problems mostly fit very badly).

Any experienced coder will know what types of problems don't work in his language, so every experienced coder wants a language that solves that problem. What not every experienced coder knows is that gain in one area typically means a loss in another area., or you move away from general purpose towards DSLs.

To give examples of the badly fitting problems that I am somewhat aware of:

I have not been able to write a state machine down in a useful and readable way so far in C++. I think some required primitive is just missing. A block of if statements for each state would work, but you need to jump between these blocks, so you need arbitrary goto. Not nice, but doable.

The real problem comes if the state machine is accessed from a callback. In that case, you need an inverted control flow. (Instead of calling a subroutine from the state machine, and returning to the same state when the subroutine is done, the state machine is inside the subroutine, and you have to jump to the right state, do some computing, and give an answer, while making sure the next call starts at the correct entry point.) General purpose languages are very bad at inverted control flow.

Twisted solves it somewhat, but it fragments your entire code to the point that you cannot see any structure in it any more. Other solutions seem to be "yield" and co-routines, but I have not enough experience with them to understand their limiatations.

Threading is another example where general purpose language don't really fit. Having to manually track and resolve data access clashes can't be the right solution. Go makes a good step, but discards all libraries that exist by folding an entire language around it. Pretty much every language does this however, which is probably why I still write silly code like loading INI files (in this case from Matlab cell arrays).

Small DSLs isn't the answer either. Take for example parser generators. It's their own language, but intertwined with magic names, types, and code fragments from another program, to make it all work. Shader source code does this too, to some extent (in the reverse way, the general purpose language uses names from the shader source). If I would move my state machine to its own language, I would have the same problem there as well. If you extend a DSL with types and expressions, it almost immediately becomes a big language, the effort to implement it explodes.

While I have not yet found the answer, I am thinking that maybe small embedded languages may be useful. When I want to write a state machine in C++, I just state "from here, use state machine language", which means I get new syntax for writing states and edges. I borrow the expression, types, and data from the C++ code. At the end I say "here state machine ends" , and I can't use the states and edges syntax any more (although perhaps, it should be possible to point at a state from C++).

You could also see it as a processing environment. If I need inverted control flow for a function, why not just state "this function must have inverted control flow", and it generates code for it.

To not go entirely off-topic: A VS extension is totally useless for me, as I work at Linux only. I wouldn't mind downloading a compiler source, and building a compiler for the language, and using a plain text editor for editing. The only requirement for me is that the language must do something useful I can't really do with another language I already have. and know.