Fair enough, your second example is harder to read because it's more of a visual jumble. But that's on the declaration side. There are also usage sites, where you don't have any labels at all, so keeping semantically related parameters adjacent is likely to significantly reduce confusion.
And regarding your point about generic generics (i.e. higher-kinded types)… they do increase the potential for visual clutter, but on the other hand, the more different kinds of things are allowed as generic parameters, the harder it will be for people to remember the required order. "Lifetimes before types" is easy to remember. "Lifetimes before types before consts before higher-kinded types before traits", not so much. (That particular order is also somewhat illogical; wouldn't it make more sense to put normal types and higher-kinded types together?) Sure, the compiler can always tell you how to fix your declaration, but it's needless friction.
Hmm... We see, but from looking at existing C++ code we disagree.
However, we can still have defaults being last-per-kind and allow arbitrary declaration and semi-arbitrary usage order. That is to say, maybe start out with last-per-kind defaults, then optionally go into arbitrary orders if that turns out to not be good enough?
I think enforcing any order between const and type generics is a bad idea. I would like for both of these things to be possible at some point:
// generic const default based on a preceding type-generic
struct Foo<T: const Default, const I = T::default()>;
// generic type default based on a preceding const-generic
struct Bar<const N: usize, T = [u8; N]>;
Perhaps the order could be enforced by rustfmt but ignored by rustc ? After all this looks like a stylistic matter, but not a syntactic problem at all.