I don't even know where to begin a serious criticism of this. Let me start by asking a question: which computer is it, exactly, that you use supports a native array type? In x86 I suppose the closest would be a 4-way SSE vector? This only captures a subset of the cases you mention. Let me continue point by point:
(1) Escape hatch. Name a real language without an escape hatch? Haskell, O'Caml, LISP, Java, C#, VB, Cobol, FORTRAN, etc. can all link to C-binaries.
(2) Distinction between arrays and pointers. Misinformation: the problem is that an array decays to its equivalent pointer type with little effort. Any conformant C++ compiler can, will, and does reject passing an explicit array, i.e., char-string literals, to a parametric type expecting a scalar; even GCC does this.
(3) "Responsible for most buffer overflows". Is it? Data? My recent reading of bug-sources in the literature does not support this.
(4) "C++ didn't have &". Again, C++ inherited the array-decaying-to-pointer from C. Maybe this is a bad idea. If you could please write a short document explaining a backwards-compatible fix for this, that'd be great.
(5) I don't really understand your STL comment. At what point is the STL --- an algorithms library --- going to replace a data-structure? Perhaps you mean that the limited set of containers in the std namespace don't fully replace an array? Perhaps. I think there are some missing random-access containers: fixed-length arrays and wrappers around raw pointer-buffers are examples. There is also a regrettable lack of trie's, R-trees, quadtrees, 2-3-trees, and the rest.
(6) "Most modern languages approach iteration...". Sure. That's why C++0x is introducing a for (i : X) [foreach] construct.
(7) "Safety." First, there is no definition of "safety." Second, even if I admit there is a workable definition of "safety", it has never been a concern for C or C++.