Sure. An important idea here is disambiguation – a big word meaning that any syntax must have one and only one meaning, and if there is any possible confusion, the language design needs to use syntax to tell different meanings apart.
An example in SC is the requirement to use parentheses around expressions for argument defaults in |arg| syntax:
f = { |a b| a }; // OK
f = { |a = 0, b = 0| a + b };
f = { |a 0 b 0| a + b }; // OK
f = { arg a = 0, b = a*2; a + b }; // OK
f = { |a = 0, b = (a*2)| a + b }; // OK
f = { |a = 0, b = a*2| a + b }; // not OK
The last one is not OK because | could have two meanings: it could end the argument block, or it could be a bitwise-OR binary operator. What is b? Is it a*2 or is it a * 2 | a + b? Well, “obviously” not the latter because then the argument block isn’t closed – but to determine this, the compiler would have to scan forward to find the presence or absence of another | token, and then go back to apply that inference. This is veeerrryyyy tricky, and it also doesn’t work for e.g. f = { | a b | c | d } – is that args a b and an expression c | d, or a = b | c and return d?
So SC makes it illegal to simplify the syntax here – because if it did simplify, you would run into cases where it’s impossible to determine the meaning. The parentheses make it clear.
In Max/Pd, lists are atoms (numbers or symbols). In SC, array elements are expressions:
[a + 2, b - 5]
vs
[ a + 2 b - 5 ] // yikes
I guess you could say “maybe sometimes the commas could be left out,” but that conflicts with #5’s call to cut back on multiple styles.
The Python way. One way to check it out is to try it:
SynthDef
\test
def // bc, also no braces for functions I guess
out = \out.kr
freq = \freq.kr
Out.ar
out
SinOsc.ar
freq
(next statement)
It could potentially be made to work, but I’m not sure it’s more friendly.
That’s been discussed. Pretty much everyone wants that requirement to be relaxed 
Do you mean to accept sinOsc or sinosc or sINOsc all as equivalents of SinOsc? I can imagine practical difficulties with that.
We actually have coding style guidelines – one problem is that new programmers are already overwhelmed with syntax and concepts, and may not yet understand why consistent styling is good for readability. So the people who need readability the most, do it the least.
The type system discussion – lots and lots about this, in this thread.
I’m of two minds about it. We get a lot of benefit from runtime dispatch (duck typing), but that benefit is easy to overlook. At the same time, getting the error six stack frames down is confusing.
Currently, adding a quark requires recompiling the class library. If we could load classes dynamically, then it would be possible.
I’m out of time for now, but the other points are thoughtful – may come back to them later.
hjh