Proper Community Engagement

You cannot ever have multiple mutable references to the same array element (or any other object, for that matter), because the borrow checker forbids it (and if you cheat and do it anyway with unsafe code, it is immediate UB because of noalias). Without mutable aliasing, it's not possible for two different parts of the program to both think they own the Nth slot in the array at the same time.

The lack of mutable aliasing must be provable at compile time just from the types of the arguments. It immediately follows that you cannot conjure a mutable reference out of thin air in safe code - it must come from something you already own or another mutable reference. It does not matter whether you're indexing into an array or doing some more complicated dance. Mutability is transitive, and all of the relevant loopholes are either protected by unsafe (UnsafeCell<T>) or by runtime checking (RefCell<T> and most of std::sync).

In the specific case of the static fake heap, this fails on several different grounds:

0. All interactions with mutable statics are unsafe, because of thread safety. Unsafe code can, of course, do a UAF in Rust. That's not news, so in order for this argument to be interesting, the whole thing must work in safe code. But we can just pretend you said "a long-lived boxed slice" instead of a static array, so let's ignore this and continue.
1. To get a mutable reference to the Nth element of an array (or slice/Vec/whatever-it-is), you must borrow the entire array mutably. It is sound to take out multiple non-overlapping mutable borrows against the same array, but you are limited by the API exposed by slice (see e.g. slice::split_at_mut()) unless you write your own unsafe code to do it manually. Regardless, you still cause the whole array to be borrowed mutably until all element borrows are returned.
2. Your array borrow must outlive the borrow of the individual element. This means that whatever part of the program thinks it owns the Nth slot in the array must not actually hold a reference to the element (or else it would prevent any other part of the program from using at least that slot in the array, if not the whole array). It may only hold an index into the array, it can only materialize that into a reference temporarily when needed, and it must receive a mutable reference to the array in order to do that. The latter reference must be constantly passed around pervasively throughout your entire program, or else the array must be protected by RefCell<T> (single-threaded) or a lock of some kind (multi-threaded). RefCell<T> will panic if you try to mutably alias the array at runtime (the locks will block, as you might expect, and if it deadlocks, oh well, that's your problem). This is still technically possible, but it looks very ugly and not at all like idiomatic code (which is what DARPA says they want as output).
3. It is not legal to drop anything in-place in safe code, because the dropped object would still be accessible, and someone might try to use it. So when we say that the object is "freed," we mean that the bitmap no longer considers it to belong to anyone. The object still exists and has a valid value. Some other part of the code might mutate it (through this careful dance of never holding a long-lived reference to anything as described above) or even replace it with an entirely new object, but it cannot replace it with random garbage. It must uphold all invariants of its type, which may be arbitrarily complicated, and which are enforced through the use of visibility restrictions. This can cause logic errors, sure, but it is a far cry from a "real" UAF in which random bytes are interpreted as some entirely inappropriate type.

I will admit that DARPA's goals seem (at best) extremely ambitious to me. But if they do succeed, their generated code will not look anything like what you describe (or else they won't have accomplished what they now claim to be trying to do).