void ten(char foo[static 10]) { }

  void generates_warning() {
    char foo[3];
    ten(foo);
  }

> warning: array argument is too small; contains 3 elements, callee requires at least 10

    char ten(char foo[static 10]);

    char ten(char foo[static 10]) { return foo[1]; }

    void generates_no_warning(void);

    void generates_no_warning() {
        char foo[30];
        ten(foo);
    }

    int main() {
        generates_no_warning();
    }

    int do_stuff(size_t len, int64_t arr[len]);

Thus we have yet another overloading of "static" in C, the use of "auto" in C++11 (which worked out quite well), and interesting type names such as "long long" in both.

When the committee breaks this rule (think nullptr in C++11) they first must choose a name which is suitably rare (and often a bit clunky as a result), they then scan for that name in large code corpuses, and evaluate how much work they are making for the maintainers of any codebase that's going to be compiled against a new compiler (and which may need to be modified to do so).

Some languages (I'm thinking JS specifically) have keywords that are not in use but are still reserved in case they may be useful in the future.

It would be extremely difficult for the compiler, without changes to the C spec and most ABIs, to simultaneously provide that protection for heap-allocated objects, for example:

    foo(malloc(30));

The most common arrays of arbitrary length in C programs are almost certainly C "strings" which are usually 0-terminated instead of including a length value.