I have two concerns with that proposal. First, it's scope is limited; it can only be used for values that are known at compile time.
Second is friction. At this point, I never specify lifetimes for variables because rust is so good at figuring them out. That has greatly improved my life as a programmer as I'm not fighting the borrow checker all the time. Constant generics look like something that will introduce friction once again as end users are suddenly faced with (possibly cryptic) errors from the compiler regarding values that aren't constant at compile time. This will be especially problematic when the user 'knows' that the values are all constant (but for some reason they aren't, and the user doesn't understand this).
This proposal allows the end user to just write what they mean, and let the compiler figure out the best place to evaluate it. And as things improve within the compiler, more and more of that work can be moved into compile-time evaluation rather than run-time evaluation.
Alternatively, since the time of evaluation is deliberately unspecified, we could have debug builds that just emit assert code, which results in very fast builds, and release modes that attempt to evaluate the constraints. We can even add level of effort switches so that programmers can choose how much time is spent evaluating the constraints before giving up and just emitting code to evaluate it at run time. This could be useful for overnight/weekend builds where the server is given many hours to do a compile, and can therefore explore a very deep graph of constraints to prove (or disprove) what is possible, and to really optimize the code.