This reminds me of reading a typical zoning ordinance: more an historical sack of bandaid reactions to specific but unrelated past problems than a positive program generating a bounded creative domain. Addressing gripes is not evaluating tradeoffs.
Successful languages start with a clear idea of what problem they want to solve, creating coherency at a high level. Values are ranked and might be nice is distinguished from what is held dear. The starting point is identifiable and the passion positive. Saying "the ending point is not here," isn't enough.
It actually reminds me of a first draft mind dump. From here, some aggressive refactoring could turn this into a very nice language specification.
Brain-dumps are valuable for discussion and as a first step. From there, we just need to follow our normal programming routines: Write, refactor, test, repeat.
I hated sounding negative on the article. It represents a lot of admirable effort. My point is that the effort is not directed in a particularly constructive direction in regard to creating a new programming language.
There's a clear goal when writing a language that is both a floor wax and a desert topping. On the other hand, all writing a language with the goal of being neither floor wax nor desert topping just gets us a floor topping and a dessert wax. There's no problem solved. Griping isn't brainstorming.
Brainstorming is structured. Productive brainstorming is constrained by reality. By which I mean that brainstorming about something like type inference acknowledges that type inference is subject to the Halting problem and that dynamic typing as in Python does not entail type inference.
Starting with Assembly, all higher level programming languages are DSL's over machine code. Things I hate is not a domain that leads to insight or a coherent minimum language. Python's core was addressing pedagogical problems such as beginners learning to format code well. Google's Closure compiler addresses the problem of JavaScript performance. Rust is intended to address client server programming. For each there is something that can be measured objectively and improved.
Don't misunderstand me, there's nothing wrong with writing a programming language as a learning exercise or to scratch one's own itch or solve the world's problems. But it is an engineering design exercise not a poem. The facts of computation make it so.
You mean that structural features like prohibition of criticism in brainstorming leads to limited and unimaginative ideas, which is the point of brainstorming in the first place, and that no one agrees on what the the structural features of brainstorming actually are in the first place?
In any case, I don't understand your writing very well because it doesn't show a lot of clarity, but if you really wanna keep up a debate, I don't mind.
We should add another stage into that routine: research.
It's no good looking at problems that other people have solved (or proven that they can't be), when we could be looking at new ways to approach problems instead. For example, we'd know that "statically inferred duck typing" is already well researched. It's called structural typing.
Successful languages start with a clear idea of what problem they want to solve, creating coherency at a high level. Values are ranked and might be nice is distinguished from what is held dear. The starting point is identifiable and the passion positive. Saying "the ending point is not here," isn't enough.