Why don’t you like the D syntax solution? It’s sufficiently clean.
D’s syntax is inconsistent between the declaration-site and the use-site (T vs. !T) and has scoping issues due to Algol-style syntax (T t) instead of Pascal-style syntax (t: T).
You can see the latter here:
T add(T)(T lhs, T rhs) {
return lhs + rhs;
}
The result type T comes before it is actually declared. See Ceylon for a similar issue:
class Id<T>() {
// Does the result type T refer to the class' <T> in scope,
// or to the method's <T> that comes after it?
T id<T>(T val) { ... }
}
Java tried to avoid exactly this with its approach:
<T> T id(T value) { ... }
which is also kinda bad, because declaration- and call-sites (foo.<Bar>(...)) cause confusion for users.
C# decided to go D’s/Ceylon’s route with T id<T>(T value) { ... }, having similar issues as those two.
Kotlin got it right originally with
fun id<T>(value: T): T { ... }
but they reverted back to
fun <T> id(value: T): T { ... }
due to an unfortunate design choice where their extension method syntax interacted badly when used with generic receivers:
fun R.id<R, T>(value: T): T { ... } // ugh, type parameters sandwiched between to uses
I don’t think it’s a good idea to conflate function calling with array access.
But that’s exactly what Rust does with its Index and IndexMut traits!
in a system language, that often has to access memory at low level, it’s good to have a syntax that clearly tells apart the two things
Then I fear Rust isn’t that language. 
Rust kinda lives in the worst of both worlds, in which [] has no meaning you can rely on, but is used anyway, so [] cannot be used for better generics.
often the change will not be regarded as important enough to break compatibility
That’s why I’d love to hear some statement on how large changes can be between major versions of Rust. It would be a disappointment if they were comparable to changes in minor versions. If you have a hard limit on the size of fixes, broken things just start piling up until the language collapses under its own complexity.
