Not to mention it's still not easy: to have any usefulness, there will need to be a way to be generic over it (similar to keyword generics), and that's far from trivial.
If this is the "trivial" implementation, then I'm not sure what a "nontrivial" implementation would look like, unless it means adding a proof-tactics language to Rust to allow statically checked proofs of arbitrary program properties. Which would be really cool and all kinds of useful, but which I think everyone realizes would be a gargantuan project even to design, let alone implement.
Genericity is not strictly required for no-panic to be useful (lots of type-system features still don't have it), but yes, it would be very nice to have. (Though one might hope that, once they figure out genericity for one keyword (probably const), that'd make it easier to add for others.)
Should indexing an array with a constant be marked? What is considered to be a constant? Those are complicated questions.
If you do not want genericity nor complicated handling, you can already get yourself covered, pretty much. Clippy has lints for panicking language operations/basic std functions, and it should be possible to write a linter that automatically infers if a function can panic.
Constants are well-defined in Rust; panicking operations like array indexing would be allowed within no-panic functions in const contexts (https://doc.rust-lang.org/reference/const_eval.html#const-co...), but not otherwise.
There's a difference between genericity over no-panicness (which I argue is not needed for an MVP) and allowing otherwise generic functions to be no-panic (which I do think is required). I don't think a linter can do the latter, because it would need to integrate with the trait system (e.g., you would need a NoPanicDrop trait and possibly NoPanicFn(|Mut|Once) traits).