Disclaimer: Author of the language / web page speaking.
This one is hopelessly outdated. See https://github.com/c3d/xl for the current state of things. A bit of history of the language here: https://github.com/c3d/xl/blob/master/doc/HISTORY.md.
Warning: this is currently under heavy repair / refactoring, so Nothing Works™.
An interesting (if old, 2010) application of the language here: http://tao3d.sourceforge.net.
Contributions and ideas welcome.
What you did there is very cool! I am speaking for both LX as presented in the old link and the new work that you are doing.
Personally I have given up creating a new programming language about a decade ago because I realized no matter what language I create, people will not use it, it it comes from a random github page.
Also, existing languages cover almost all business needs and while languages like LX provide a lot of improvements, the cost of change seems to be greater than the cost of not having these improvements.
As for ideas, what I'd like to see in a programming language is signal-based programming: the execution flow of a program is not 'one instruction after the other' but reactions to signals. A program shall be built by wiring output signals to input signals.
I'd also like to see types morph based on run-time conditions.
The most fundamental problem of all the current programming languages is that types are too rigid and don't allow for catching all the possible outcomes. For example, a File morphs between a closed file and an opened file, however in current systems any operation can be applied to a file, irrespectively of whether the file is actually opened or closed.
I believe that the combination of signal-based programming and type morphing will increase the reliability of programs, leaving only bugs that cannot be proven to be solved due to their nature (aka like the halting problem).
I may not be necessarily correct, but I have a strong belief in the above.
Speaking as a fellow sufferer, how did perl, python, php, lua, ruby start getting used? They were pre-github, but jq really did start that way: https://github.com/stedolan/jq.
The key to being used is a usage: a problem to apply it to. If there's a problem that people need solved, and your language is much better than the alternatives, then people will use it, post about it, rave about it. If JSON wasn't popular, jq wouldn't be popular.
OTOH your actual interest is in more abstract ideals. This is crucially important work, but you may be right that no one will use it... instead, they'll be interested in the ideas you are interested in. Finding a needed application of your ideas will generate use.