Things have gotten off-topic I think…
My vote is against a semicolon and simply use comma with const N: type (and using curly braces where/if needed). Adding a semicolon would be a completely separate way of specifying parameters and usage, where we’ve already got an example of lifetime parameters that still use commas, so things suddenly get very inconsistent. While initially the feature will be used for arrays, as the feature gets expanded upon (and other features like const fns may appear), I doubt it that will be the primary use case, so why tie ourselves to a very one-off special case of arrays? A semi-colon also ties us to a very specific ordering of parameters. What if, after testing the feature out a lot, it turns out it make more sense for const parameters to appear before lifetimes, or even before type parameters, or interspersed? It’s very inflexible to have that hard grouping, especially when two other parameter kinds don’t have a hard grouping that can easily be fiddled with.
On a related note, I’m very much in favor of the idea presented of type parameters having an implicit type specifier, and ' being shorthand for a lifetime specifier, and then adding a new const specifier (alternatively, use a const sigil, but that’s just a bad idea, I’m already not a fan of lifetime quote). This gives good consistency that is also forward-compatible any new type parameters (i.e. higher-kindred types), if we so desire. Obviously, that’s a bit beyond the scope of this feature and should be it’s own RFC, but I think it points out how not using a semi-colon would be more consistent syntax going forward (with or without other specifiers happening).
Additionally, I’d be in favor of the same thing applying to use outside the initial definition, with const being optional but implicit in cases that make sense, e.g. Foo<{N}> or even just Foo<N> (assuming no compiler ambiguity) would be identical to Foo<const N>. Making the specifier optional allows you to be explicit when you want for readability but without getting in the way when that’s not an issue. As much as I dislike the quote on lifetimes, having it be clear when lifetime is being used outside definition is very useful (but also sometimes it’s just not needed either). Basically along the lines of what lang team is trying to do with more lifetime elisions. When braces are required, this obviously doesn’t make much difference, but maybe Foo<{N + 1}> being shorthand for Foot<const {N + 1}> might also be useful for forward compatability (but I can’t come up with other possibilities that would be ambiguous like how expressions vs. trait requirements is)
And as for identifier naming, that seems like something that a style RFC could cover and not very useful to getting this feature put in place? Enforcing a lint on arbitrary identifier style right now seems out of place before the feature has been implemented?